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(54) Methods and arrangements in a telecommunications system 



(57) The invention is related to a digital, wired or 
wireless, communication system constituting a network 
of multiple nodes. The network comprises a central 
node. The central node controls all the communication 
in the network. In such a system, information related to 
the system itself or to the nodes in the system can be 
distributed by the central node among the peripheral 
nodes in the network or kept in a database in the central 



node, which database is accessible on request from the 
peripheral nodes in the network. The information can be 
conveyed to the central node from the peripheral nodes, 
either commanded by the central node itself or on re- 
quest from a peripheral node, triggered by an internal 
event in the peripheral node, e.g. a change of state hav- 
ing external consequences. 

The invention provides a mechanism for efficient 
distribution of relevant information in such a system. 
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Description 

FIELD OF INVENTION 

[0001] The present invention relates to a method and 
arrangement in a digital communication system consti- 
tuting a network of multiple nodes. More specifically the 
present invention relates to a method and an arrange- 
ment for providing distribution within a Piconet using 
short range radio technology. 

DESCRIPTION OF RELATED ART 

[0002] The Bluetooth interface is an example of a 
short-range radio interface, which was originally intend- 
ed as a replacement for cables between electrical de- 
vices. The term Bluetooth is in this disclosure used as 
an example of usage of short-range radio communica- 
tion. Printers, digital cameras, telephones, laptop com- 
puters, video monitors, electronic calendars (PDA), 
desktops, fax machines, keyboards, joysticks as well as 
ordinary computers and virtually any other digital device 
can be part of such a short-range radio system, i.e. any 
of these devices could have a Bluetooth radio chip and 
the software required therefore. But beyond untethering 
devices by replacing cables, short range radio commu- 
nication can provide a universal bridge to existing data 
networks, as a peripheral interface. It can also be used 
to form small private ad hoc groupings of interconnected 
devices away from fixed network infrastructures or con- 
nected to a fixed network infrastructure via a gateway. 
The Bluetooth radio communication system is designed 
to operate in a noisy radio frequency environment and 
uses therefore a fast acknowledgement and frequency 
hopping scheme to make the links between the units in 
the system robust. Thus, Bluetooth radio modules avoid 
interference from other signals by hopping to a new fre- 
quency after transmitting or receiving a data packet, as 
is illustrated in Fig. 5. Compared to other systems oper- 
ating in the same frequency band, the Bluetooth radio 
communication system typically hops faster and uses 
shorter data packets. This makes the Bluetooth radio 
communication system more robust than other systems. 
Use of Forward Error Correction (FEC) limits the impact 
of random noise on long-distance links between units in 
the system. 

[0003] A Bluetooth radio communication system uses 
a frequency hopping scheme within the unlicensed ISM 
(Industrial, Scientific, Medical) band at 2.4 GHz. A fre- 
quency hop transceiver is used in the units to reduce 
the influence of interference and fading. A shaped, bi- 
nary FM modulation scheme is used to minimize the 
complexity of the transceiver. The gross data rate is 
1Mb/s and a TDD (Time-Division Duplex) scheme is 
used for full-duplex transmission. 
[0004] The Bluetooth base band protocol is a combi- 
nation of circuit and packet switching, as is shown in Fig. 
5. In Fig. 5, si denotes a single time slot, and p1 denotes 



a packet the transmission of which requires three time 
slots. The packets are normally transmitted using differ- 
ent hop frequencies. A packet is nominally transmitted 
in a single slot, but a single packet can require up to five 

5 slots. Bluetooth can support an asynchronous datj^ 
channel, up to three simultaneous synchronous voice 
channels, or a channel, that simultaneously supports 
asynchronous data and synchronous voice. Each voice 
channel supports a 64 kb/s synchronous (voice) link. 

10 The asynchronous channel can support an asymmetric 
link of maximally 721 kb/s in either direction while per- 
mitting 57.6 kb/s in the return direction, or a 432.6 kb/s 
symmetric link. 

[0005] In Fig. 2, function blocks of a unit having a 
15 short-range radio transceiver, such as Bluetooth, are 
shown. A radio unit 300 provided with an antenna is con- 
nected to a link control unit 310 providing the base band. 
The link control unit 310 is connected to the Central 
Processing Unit, called CPU, 320 providing the link 
20 management. The CPU is connected to a memory 360 
storing the software and consisting of two memory units: 
an SRAM 330 and a FLASH memory 340. The CPU 320 
is connected to a host interface 350. An SRAM is a fast 
temporary memory. A FLASH memory is programmable 
25 ROM. 

[0006] Fig. 8 shows two piconets A1 and B1 in a scat- 
ternet. The piconet A1 comprises four units 10, 20, 30, 
40; and the piconet B1 comprises three units 40, 50 and 
60. In the piconet A1, the unit 10 is a master unit. The 

30 unit 40 is a member of both piconet A1 and piconet B1 . 
Two or more Bluetooth units (BT) using Bluetooth for 
communication with each other and sharing the same 
channel (i.e. the same frequency hop sequence and 
time slot synchronization) form a piconet, i.e. a piconet 

35 is a collection of units interconnected using Bluetooth in 
an ad hoc fashion. Within a piconet a Bluetooth unit can 
have either of two roles: it can be a master or a slave. 
Within each piconet there is one and only one master, 
and up to seven active slaves can be connected, i.e. a 

*o piconet starts with two interconnected units, such as 
portable PC and a cellular telephone, and it may grow 
to eight interconnected units. All Bluetooth units are 
peer units and basically have identical implementations. 
Any BT unit can become the master in a piconet. How- 

<5 ever, when a piconet is being formed, one unit will take 
the role of the master and the other(s) will be slave(s) 
for the duration of the piconet. A scatternet, or an ad hoc 
network, is a network comprising multiple independent 
and non-synchronized piconets. The master or master 

50 unit is the unit in a piconet the clock and hopping se- 
quence of which are used to synchronize all other units 
in the piconet. A slave or slave unit is every unit in a 
piconet that is not the master in the piconet. Two or more 
piconets can be interconnected, forming a scatternet as 

55 has already been defined. The connection point be- 
tween two piconets consists of a single BT unit that is a 
member of both piconets. A BT unit can simultaneously 
be a slave of a plurality of piconets, but only master in 
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one piconet. I.e., a BT unit functioning as master in one 
piconet can act as a slave in another piconet or piconets. 
A BT unit can only transmit and receive data in one pi- 
conet at a time, so participation in multiple piconets has 
to be on a time division multiplex basis. The Bluetooth 
system supports both point-to-point and point-to-multi- 
point connections. Several piconets can be linked to- 
gether ad hoc, where each piconet is identified by a dif- 
ferent frequency hopping sequence. All units participat- 
ing in a same piconet are synchronized to the hopping 
sequence of the piconet. The scatternet topology can 
best be described as a multiple piconet structure, see 
Fig. 8. However, Bluetooth units for use in scatternets 
are not yet commercially available. 
[0007] Fig. 3a shows a Personal Digital Assistant 
PDA 500 utilizing an "add-on" Bluetooth communication 
device 510. The Bluetooth communication unit 510, 
which is provided with an antenna, is inserted in a slot 
in the PDA. The Bluetooth communication unit may be 
a PC-card or a compact flashcard provided with a Blue- 
tooth chipset. 

[0008] Fig. 3b shows a PDA utilizing a "built-in" Blue- 
tooth communication device. Here, the PDA is provided 
with an antenna. 

[0009] Fig. 3c shows a mobile telephone utilizing a 
"built-in" Bluetooth communication device, the Blue- 
tooth transceiver having an antenna, not shown, differ- 
ent from that of the mobile telephone. 
[0010] A Bluetooth system provides, as already told, 
full-duplex transmission built on slotted Time Division 
Duplex (TDD). Each slot used has a length of 0.625 ms. 
The time slots are numbered sequentially using a very 
large number range (the range is cyclic having a cycle 
of 2 27 ). Transmission from master to slave always starts 
in an even-numbered time slot whereas transmission 
from slave to master always starts in an odd-numbered 
time slot. The term "frame" as used here is defined as 
the combination of an even numbered time slot and the 
subsequent odd numbered time slot (i.e. a master-to- 
slave time slot and a slave-to-master time slot), except 
when multi-slot packets are used, and then other con- 
ventions are used. In a communication system using 
Bluetooth no direct transmission exists between slaves 
in a piconet. 

[0011] The communication between the units of a pi- 
conet is organized such that the master polls each slave 
according to some polling scheme. With one exception 
a slave is only allowed to transmit after having been 
polled by the master. The slave will then start its trans- 
mission in the slave-to-master time slot immediately fol- 
lowing the packet received from the master. The master 
may or may not include data, e.g. payload data, in the 
packets used to poll the slave. The only exception to the 
above principle is that when a slave has an established 
SCO (Synchronous Connection-Oriented) link to the 
master, it is always allowed to transmit in a pre-allocated 
slave-to-master slot, even if not explicitly polled by the 
master in the directly preceding master-to slave slot. 



SCO links support real time voice traffic using reserved 
bandwidth. 

[0012] Each BT unit has a globally unique 48 bit ad- 
dress. This address, the Bluetooth Device Address 
5 (BD ADDR) is assigned when the BT unit is manufac- 
tured and it is never changed. In addition thereto, the 
master of a piconet assigns a local Active Member Ad- 
dress (AMADDR) to each active slave of the piconet. 
The AM ADDR is only three bits long and is unique only 
within a single piconet. The master uses the AM ADDR 
when polling a slave in a piconet. When the slave, trig- 
gered by a packet received from the master and ad- 
dressed using the AM_ADDR of the slave, transmits a 
packet to the master, it includes its own AM_ADDR in 
the header of the packet. 

[0013] The packets can carry both synchronous data, 
on Synchronous Connection Oriented (SCO) links, and 
asynchronous data, on Asynchronous Connection-Less 
(ACL) links. For some types of packet used, an acknowl- 
edgment and retransmission scheme is used to ensure 
reliable transfer of data. Such a scheme is not used for 
SCO packets transferring synchronous data. Also for- 
ward error correction (FEC) in the form of channel cod- 
ing can be used. 

[0014] The standard format of a Bluetooth Baseband 
packet is shown in Fig. 1a. It comprises a field for an 
access Code, a header field and a payload field. The 
Fig. 1c illustrates the format of the header field, which 
comprises an AM_ADDR field, followed by a TYPE field, 
indicating the type of packet. The FLOW field encom- 
passes one bit used for flow control. The fields ARQN 
and SEQN control the acknowledgement and retrans- 
mission scheme. The Header Error check (HEC) field 
has information for checking the integrity of the header. 
In receiving a packet and using the information in the 
HEC field for checking the header field. The header field 
can be found to be in error and then the packet is dis- 
carded. Otherwise the packet is retained and further 
checks can be made. The format of the payload de- 
pends on the type of packet being transferred. An SCO 
packet is a packet transported on an SCO link and an 
ACL packet is a packet transferred on an ACL link. The 
payload field of a SCO packet comprises only a data 
field. The payload of an ACL packet, which is shown in 
Fig. 1b, comprises a header field, a data field and, a field 
carrying information for cyclic redundancy check (CRC). 
In addition, there are hybrid packet including two data 
fields, one for synchronous data and one for asynchro- 
nous data. Hybrid packets are used when voice infor- 
mation and data are transmitted over the same link. 
Packets having a payload field and not provided with a 
CRC field are neither acknowledged nor retransmitted. 
There are two different formats of the payload header 
field. In Fig. 1d the format of the payload header field 
for single-slot packets is illustrated. In Fig. le is illustrat- 
ed the format of the payload header field for multi-slot 
packets. L_CH is a two bit field indicating the type of 
payload. L_CH=00 means that the "00" value is unde- 
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fined, and will therefore not be used. L_CH=01 indicates 
a continuation fragment of an L2CAP message to be de- 
scribed below. L_CH=01 indicates the start of a L2CAP 
message or no fragmentation. Fragmentation means 
that the L2CAP packet is to large to be carried by a sin- 
gle Basband packet and therefore it has been split into 
multiple parts, so-called fragments, each fragment be- 
ing carried by a single Baseband packet. At the desti- 
nation node the fragments are reassembled into a com- 
plete L2CAP packet. L_CH=11 indicates an LMP mes- 
sage. The FLOW field is used for flow control. The 
FLOW bit in the header field is used for flow control at 
the L2CAP level. FLOW=0 indicates "stop transmis- 
sion". FLOW=1 indicates "ready for transmission". The 
FLOW bit in the last correctly received payload header 
determines the flow status. The LENGTH field indicates 
the length of the data field. Since multi-slot packets can 
carry a longer data field, the LENGTH field of the multi- 
slot payload header (Fig. le) is longer (not shown in the 
figure) than the LENGTH field of the single-slot payload 
header (Fig. 1d). As is shown in Fig. le, the payload 
header field of a multi-slot packet, the four last bits are 
undefined. 

[0015] In a Bluetooth system a few protocol layers are 
used which are illustrated in Fig. 4 and comprise the 
Baseband (BB), protocol between the physical layer 103 
and the data link layer 104, the Link Manager Protocol 
(LMP) and the Logical Link Control and Adaptation Lay- 
er Protocol (L2CAP)in the data link layer 104. Also a 
"High level protocol or application" layer (106) may or 
may not be provided as well as a Network layer (105) 
is. In addition, a Network Adaptation Layer (NAL), not 
shown, residing between the data link layer (104) and 
the network layer (105) can be provided. 
[0016] Now the Bluetooth protocol stack will be de- 
scribed with reference to Fig. 4. In Fig. 4 two Bluetooth 
units are depicted: a unit Nr. 1, 101, and unit Nr. 2, 102. 
[0017] The BaseBand BB protocol describes the 
specifications of the digital signal processing part of the 
hardware - the Bluetooth link controller, which carries 
the Baseband protocols and other low-level link rou- 
tines. It uses two link types: Synchronous Connection- 
Oriented (SCO) links and Asynchronous Connection- 
Less (ACL) links. The Link Management Protocol LMP 
handles messages used for link set-up, security and 
control. The LMP is located above the Baseband Pro- 
tocol. 

[0018] The Logical Link Control and Adaptation layer 
Protocol L2CAP is also located over the Baseband Pro- 
tocol. L2CAP provides connection-oriented and con- 
nectionless data services to upper layer protocols with 
protocol multiplexing capability, segmentation, reas- 
semble operation, and group abstractions. The L2CAP 
is defined only for ACL links. 

[0019] As previously stated, physical transmission in 
a piconet is allowed exclusively between the master and 
each slave, and viceversa. Thus, there is no way for a 
slave to send data to another slave in a piconet, since 



direct communication is not allowed. 
[0020] In a Bluetooth system there is no way specified 
to address and route packets from one piconet to an- 
other. However, a BT unit, which is a member of more 
5 than one piconet can be used to forward packets from 
one piconet to another. Such a BT unit is herein called 
a "forwarding node". 

[0021] In order to allow slave-to-slave communication 
in a piconet and inter-piconet communication. One 

10 piece of important information is a slave, which is to 
send a message to another slave in a piconet, e.g. the 
address, such as BD_ADDR of each of the other mem- 
bers of piconet. This information is normally only known 
by the master unit in a piconet. Another example of im- 

15 portant information can be whether a receiving BT unit 
supports slave-to-slave communication. 
[0022] Nokia has proposed to the Bluetooth SIG (Spe- 
cial Interest Group), the organization writing the Blue- 
tooth standard, a new method enabling inter-piconet 

20 routing in a scatternet as well as intra-piconet routing 
between slaves within the same piconet. In the Nokia 
proposal a protocol layer called Virtual Network Seg- 
ment (VNS) is inserted between the L2CAP and the Net- 
work layer 104, see Fig. 4, in order to emulate a shared 

25 medium network, i.e. a broadcast medium, to the Net- 
work layer, i.e. the VNS layer serves the same purpose 
as the NAL layer. The VNS entity in a forwarding node 
will register itself in the master unit by sending a mes- 
sage to its peer entity in the master unit. In the transfer 

30 of messages slave units use the knowledge of the mas- 
ter. When a slave unit wants to send a message to a 
forwarding node, e.g. a request to create a route to a 
specific destination in another piconet, it sends the mes- 
sage to the master unit. The master unit will then forward 

35 the message to the appropriate forwarding node(s) 
based on its retained information. 
[0023] Another example arising from Bluetooth Core 
Specification 1.0, (i.e. Specification of the Bluetooth 
system; Core; Specification Volume 1:1, version 1 .0) re- 

40 lates to the compatibility between different BT units. 
When two BT units communicate over a direct wireless 
link, i.e. not slave-to-slave communication via the mas- 
ter unit, the compatibility problem is solved by exchang- 
ing lists of features including indications for each feature 

^5 whether it is supported or not. This information ex- 
change is performed using the LMP PDU (Protocol data 
Unit), LMP_features_req and LMP_features_res. A 
message in the Link Manager Protocol (LMP) is called 
"LMP PDU", PDU standing for "Protocol Data Unit". 

50 LMP_features_req and LMP_features_res indicate two 
LMP PDU according to the Bluetooth Core Specification 
1.0. In fact, before this information exchange is per- 
formed a BT unit is allowed to use only a small subset 
of the Bluetooth features, e.g. packet types, when com- 

55 municating with the other BT unit. After the information 
exchange has occurred the intersection of the support- 
ed features in the two BT units may be used. The infor- 
mation being exchanged using LMP_features_req and 
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LMP_features_res is a list of Bluetooth features and a 
bit for each feature. The bit indicates whether the feature 
is supported or not, see page 235-236 in the Bluetooth 
Core Specification Volume 1:1. 

SUMMARY OF THE INVENTION 

[0024] The Problems discussed in the present disclo- 
sure are the following: 

The VNS approach deals with only a small part of 
the general distribution of information. 

• Regarding the LMP procedure for exchange of lists 
of supported features, this is limited to BT units 
communicating over a direct link, i.e. a master unit 
and a slave unit communicating with each other. 
The compatibility issues arising when slave-to- 
slave communication is considered are not ad- 
dressed. 

When slave-to-slave communication within a pi- 
conet is introduced, a problem is that neither the 
AM_ADDR nor the BD_ADDR, or a possible IP ad- 
dress, of other slave units in said piconet are avail- 
able for a slave unit in said piconet. Since Bluetooth 
is the main target of the invention, the method and 
arrangement as disclosed herein is described in a 
Bluetooth context using Bluetooth terminology. The 
term "Bluetooth" is a registered trademark denom- 
ination of a short-range radio transceiver and the 
communication system using such a transceiver. A 
man skilled in the art understands that other types 
of short range communication may be used, e.g. in- 
frared light, the devices in such a system being pro- 
vided with means for communication by infrared 
light. Further types of short-range communication 
may be ultrasonic or hydrophonic communication. 
Furthermore, the invention can be applicable, to 
other network technologies, both wired and wire- 
less. 

[0025] Thus a target system is considered which is a 
digital, wired or wireless, communication system consti- 
tuting a network of multiple nodes. The network com- 
prises a central node, also called master and two or 
more peripheral nodes, also called slaves or slave units. 
The central node controls all the communication in the 
network. On the lowest protocol layer, the physical layer, 
all the communication flows exclusively between the 
central node and a peripheral node or vice versa. No 
communication, on the lowest protocol layer, goes di- 
rectly between two peripheral nodes. In such a system, 
information related to the system itself or to the nodes 
in the system can be distributed by the central node 
among the peripheral nodes in the network or kept in a 
database in the central node, which database is acces- 
sible on request from the peripheral nodes in the net- 



work. The information can be conveyed to the central 
node from the peripheral nodes, either commanded by 
the central node itself or on request from a peripheral 
node, triggered by an internal event in the peripheral 
5 node, e.g. a change of state having external conse- 
quences. The distributed information can comprise: 

Number of peripheral nodes 

10 • Addresses of peripheral nodes 

IP addresses of all nodes 

Associations between an IP address and a low layer 
is address (e.g. Medium Access Control MAC ad- 
dress) for a peripheral node or for all nodes 

Addresses of forwarding nodes 

20 • Supported features of peripheral nodes 

• State changes in peripheral nodes (e.g. when a 
node becomes or ceases to be a forwarding node) 

25 • Forwarding bit rate capacity of forwarding nodes 

Notifications when nodes join or leave the network 

Notifications when a connection to a fixed infra- 
30 structure becomes available or ceases to be avail- 
able 

Notifications of other events 

35 • Information related to forwarding policy 

[0026] Furthermore, it should be noted that the meth- 
ods to be used in a Bluetooth system are not limited to 
the type of information mentioned in conjunction with the 
40 mechanisms. Any type of information related to the sys- 
tem of the individual nodes could be managed using any 
of the described mechanisms. Such information may be 
the above listed information and can contain: 

45 • AM_ADDR of slaves 

BD_ADDR of slaves 

IP address of slaves 

50 

Inter-piconet scheduling parameters for forwarding 
nodes 

[0027] Thus, to overcome the above described prob- 
55 lems and to provide a generally viable solution a piconet 
must include an efficient mechanism to make all the rel- 
evant information available to all slave units in a timely 
manner. This can be achieved in different ways. Al- 
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is a diagram illustrating a standard 
base band packet format, 
is a diagram illustrating the format of 
an ACL packet. 

is a diagram illustrating a base band 
packet header. 

is a diagram illustrating a base band 
payload header for a singe slot pack- 
et. 

is a diagram illustrating a base band 
payload header for a multi slot pack- 
et. 

is a schematic view illustrating a 
Bluetooth transceiver, 
are schematic views of three elec- 
tronic devices provided with a Blue- 
tooth transceiver. 

is a diagram illustrating the Bluetooth 
protocol layers. 

is a diagram showing the relationship 
between time slots and frequency 
hops in a system using Bluetooth, 
is a diagram illustrating a forwarding 
scenario. 

are diagram illustrating the Base- 
band packet format, 
is a schematic view of two piconets 
in a scatternet. 

is a flowchart illustrating the routing 
of a packet. 

is a diagram illustrating a Bluetooth 
unit. 

is a flowchart illustrating the process 
of a Bluetooth unit becoming a for- 
warding node, 

are flowcharts illustrating an exam- 
ple of a process when a Bluetooth 
unit becomes a forwarding node, 
are flowcharts illustrating an other 
example of a process when a Blue- 
tooth unit becomes a forwarding 
node. 

is a flowchart illustrating the process 
of a forwarding node ceasing to be a 
forwarding node and the information 
flow in a first piconet. 
are flowcharts illustrating the proc- 
ess of a forwarding node ceasing to 
be a forwarding node and the infor- 
mation flow in a second piconet. 
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though different types of information will be 
in conjunction with different mechanisms, the distribu- 
tion of all the different types of information could be han- 
dled by a common protocol, but separate protocols are 
also feasible. It is also possible to use different protocols 
for the same information in different situations. 
[0028] The purpose of the invention is to provide 
mechanisms for efficient distribution of relevant informa- 
tion in a piconet 

[0029] In a system using Bluetooth technology, an ad- 
vantage of the herein disclosed method and arrange- 
ment is that slave-to-slave communication is facilitated, 
since distribution of useful system or node related infor- 
mation in a piconet is enabled. When slave-to-slave 
communication is enabled it is no longer enough that 
the master unit is informed of relevant information re- 
garding the slave units. Useful information can be e.g.: 

• Address information related to the member units in 
a piconet, including notifications when BT units join 
or leave the piconet. 

Forwarding node information, which also facilitates 
inter-piconet communication. 

Compatibility related information. 

[0030] In a system using Bluetooth technology, a fur- 
ther advantage of the herein disclosed method and ar- 
rangement is that slave-to-slave LMP PDU also facili- 
tates slave-to-slave communication. 
[0031] In a mobile telecommunication constituting a 
network of multiple nodes, comprising a central node 
and at least two peripheral nodes, where the central 
node control all the communication in the network, an 
advantage of the herein disclosed method and arrange- 
ment is that communication between peripheral nodes, 
via the central node, is facilitated, since relevant infor- 
mation related to the system and the individual nodes 
can be distributed among the peripheral nodes. The in- 
formation may be any of the above listed. 
[0032] The term "comprises/comprising" when used 
in this specification is taken to specify the presence of 
stated features, integers, steps or components but does 
not preclude the presence or addition of one or more 
other features, integers, steps, components or groups 
thereof. 

[0033] Further scope of applicability of the present in- 
vention will become apparent from the detailed descrip- 
tion given hereinafter. However, it should be understood 
that the detailed description and specific examples, 
while indicating preferred embodiments of the invention, 
are given by way of illustration only, since various 
changes and modifications within the spirit and scope 
of the invention will become apparent to those skilled in 
the art from this detailed description. 



[0035] The invention will now be described in more 
detail with reference to preferred exemplifying embodi- 
ments thereof and also with reference to the accompa- 
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nying drawings. 

DETAILED DESCRIPTION 

[0036] The internal logical structure of a Bluetooth unit 5 
having an enhanced communication capability appears 
from Fig. 10. The Bluetooth unit 1195 comprises basic 
Bluetooth functions 11 50, forwarding functions 1 160 and 
a database 1180. The block basic Bluetooth functions 
1150 comprises the functions performed by a transceiv- 10 
er, a clock, a memory, a power source, logic circuits for 
implementing the Bluetooth protocol stack, logic circuits 
for analyzing signaling messages and logic circuits for 
generating signaling messages, etc. The block forward- 
ing functions 1160 comprises the functions performed *5 
by forwarding logic circuits, i.e. logic circuits to receive 
a packet in a first piconet, logic circuits to analyze the 
routing and address information located in said packet 
and logic circuits for transmitting a packet to a second 
piconet, etc. The block database 1180 comprises a 20 
physical memory for storing data, a piconet indicator 
1198, blocks 1197 provided with data related to each 
piconet in which the BT unit is currently a member, a 
block 1179 comprising inter-piconet scheduling param- 
eters, a block 1178 comprising BT unit related data. The 25 
block 1 198 comprising a piconet indicator includes a da- 
ta unit indicating the piconet, if any, in which the BT unit 
is currently active, i.e. which set of piconet related data 
that is currently valid. The block 1179 "Inter-piconet 
scheduling parameters" include timing parameters gov- 30 
erning when the BT unit is to be active in each piconet, 
i.e. when to switch from one set of piconet related data 
(in particular the radio related parameters 1173 and the 
timing parameters 1 1 75) to another. The block 1 1 78 "BT 
unit related data" includes data related to the BT unit 35 
irrespective of the piconet to which the BT unit is located 
e.g. Battery status, user interface options, data entered 
by the user. The blocks 1197 "Data related to the k th pi- 
conet" comprises a block 1196 "master/slave indicator", 
a block 1194 "forwarding node/non-forwarding indica- 40 
tor", a block 1192 "forwarding related data", a block 1190 
"list of piconet members", i.e. Bluetooth units that are 
connected to the piconet, a block 1170 "list of forwarding 
nodes in the piconet", a block 1173 "radio related pa- 
rameters", and other piconet related data. The block 45 
1196 "master/slave indicator includes a data unit indi- 
cating whether the BT unit is a master or a slave in the 
piconet. The block 1194 "forwarding node/nonforward- 
ing node indicator" includes a data unit indicating wheth- 
er the BT unit is a forwarding node or not in the piconet. 50 
The block 1192 "forwarding related data" includes data 
necessarto perform forwarding of data from one piconet 
to another, e.g. list of piconet being currently intercon- 
nected. The block 1173 "radio related parameters" com- 
prises frequency hop sequence and currently used 55 
transmitter power, The block 1175 "timing parameters" 
include an estimate of the clock value of the master unit. 
The block 1170 list of forwarding nodes comprises a da- 
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ta record of each forwarding node in the piconet, each 
data record comprising at least 

The AM_ADDR of the forwarding node 

The BD_ADDR of the forwarding node The block 
1190 list of piconet members comprises 

• A data record of each member unit of the piconet, 
except in some cases the Bluetooth unit itself, each 
record comprising 

• The AM_ADDR of the Bluetooth unit 

• The BD_ADDR of the Bluetooth unit 

Other optional information about the Bluetooth unit, 
e.g. compatibility information 

[0037] In order to allow that information is transferred 
from one slave to another slave in a piconet the infor- 
mation on the members of the piconet must be distrib- 
uted to all members of the piconet. Thus, when a source 
slave unit is to transfer information to another slave unit 
the source slave must have access to the address of the 
other slave unit. This address could be the BD_ADDR 
or the AM_ADDR or some other address used on a high- 
er layer, e.g. the IP address. The best choice of address 
depends on the addressing scheme used in the piconet. 
A combination of several addresses could sometimes 
also be used to allow translation between addresses, e. 
g. between an IP address and a BD_ADDR and/or be- 
tween a BD_ADDR and an AM_ADDR. 
[0038] Thus, e.g. the AM_ADDR and the BD_ADDR 
of all slaves should be made available to all slaves. 
[0039] When transferring information between slaves 
in a piconet the routing is performed using the Baseband 
layer protocol, thereby eliminating the need to traverse 
all the protocol layers up to the network layer 105 or a 
NAL layer. The packets containing the information to be 
transferred can be called Baseband Packets and they 
are transferred from a first slave, via the master, to a 
second slave. The first slave obtains the address of the 
second slave from the master, inserts it in a header field 
of the Baseband packets and transmits them to the mas- 
ter. The master analyses the address in the header and 
forwards the packet to the second slave according to 
the address. Furthermore, when AM_ADDR is used ad- 
dressing, the data overhead represented by a higher 
layer destination address (e.g. an IP address on the IP 
layer or a BD_ADDR on the NAL layer) is completely 
eliminated. 

[0040] To make the presence of a new member, and 
the relevant address(es) of this new member, known to 
the other slave units in the piconet as soon as possible, 
it is preferable that the master unit distributes the ad- 
dress information of the new slave unit as soon as the 
new slave unit has been connected to the master. The 
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master unit should also inform the new slave unit of the 
slave units being already present in the piconet, by 
transferring the relevant information and in particular the 
address information for all the already existing slave 
units. Similarly, the master unit informs all the other 
slave units in the piconet, when a slave unit leaves the 
piconet. When a slave unit leaves the piconet it is de- 
tected explicitly or implicitly by time-out due to loss of 
radio contact. An alternative distributing mechanism is 
that the master periodically distributes the address in- 
formation of all the slave units in the piconet. Of course, 
it is also possible to combine "event triggered" the time 
driven distribution of information. 
[0041] The distribution mechanism could be either 
broadcasting to all the piconet members at once, al- 
though the Bluetooth intra-piconet broadcast mecha- 
nism is not reliable, since the messages are not ac- 
knowledged, or unicast from the master unit to each 
slave unit, one at a time. If the address information of 
all the slave units is periodically unicast to each slave 
unit, the address information of the slave unit receiving 
the information should of course be excluded from the 
message. The protocol to be used could be LMP (in- 
cluding new PDUs) or a VNS layer protocol. There are 
also other proposals of adaptation layers between 
L2CAP and the Network layer, e.g. called Network Ad- 
aptation Layer (NAL), which could also include this pro- 
tocol. Other protocols may also be used for this purpose. 
[0042] A BT unit can only transmit and receive data 
in one piconet at a time, so participation in multiple pi- 
conets has to be on a time division multiplex basis. The 
time spent in each piconet is governed by a scheduling 
algorithm. This algorithm could be designed in various 
ways according to different principles, e.g. fixed round 
robin, negotiation between a slave unit and a master unit 
(when applicable), dynamically assigned time windows 
(by the master of a piconet based on the current traffic, 
etc. When a BT unit switches from one piconet to an- 
other, it has to start using another set of piconet related 
data, as shown in fig. 10. In particular, the radio related 
parameters, e.g. the frequency hop sequence, and the 
timing parameters, e.g. the clock value of the master of 
the piconet, have to be switched in order for the Blue- 
tooth unit to be able to communicate in the new piconet. 
In fig, 10 different sets of piconet related data in a BT 
unit are illustrated, as well as a piconet indicator indicat- 
ing which of the sets of piconet related data that is cur- 
rently valid. 

[0043] To allow inter-piconet communication, the ad- 
dress of each forwarding node that is present in the pi- 
conet must also be distributed. This address could be 
AM_ADDR, the BD_ADDR, an IP address or even a 
VNS or NAL specific address, or similar address. In the 
same way as for general address information of a slave 
member, also in this case, any combination of these ad- 
dresses could be useful depending on the addressing 
and routing mechanisms used in the piconet and the 
scatternet, and the independent use of the address in- 
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formation. Distribution of forwarding node information 
could be handled separately or in conjunction with the 
distribution of the general address information of all the 
slave units in the piconet. If provided in conjunction with 

5 the distribution of address information, there could be 
an indicator for each slave unit indicating whether it is a 
forwarding node or not. When forwarding node informa- 
tion is considered, this concerns the master too, since 
the master may also be a forwarding node. If the for- 

10 warding node information is distributed along with the 
slave unit address information, and the master unit hap- 
pens to be a forwarding node, this status of the master 
unit has to be added to the information of the slave units. 
[0044] Even if the forwarding node information is in- 

15 eluded in the distribution of slave unit address informa- 
tion, it must still be possible to distribute forwarding node 
information separately if event triggered distribution is 
used. When a BT unit becomes a forwarding node, the 
other members of the piconet must be informed. Like- 

20 wise, when a BT unit ceases to be a forwarding node, 
the other piconet members should be informed. This in- 
formation could be broadcast or unicast by the master 
unit to the other slave units, but first the concerned BT 
unit, i.e. the unit that become or cease to be a forwarding 

25 node, must inform the master unit. This is preferably 
done via messages on the VNS layer or NAL layer, or a 
similar layer, but the messages could also be carried by 
new LMP PDUs or by another protocol. 
[0045] In a further embodiment, the BT unit that has 

30 changed its forwarding status, from not being a forward- 
ing node to being one or vice versa, notifies the other 
piconet members directly via slave-to-slave communi- 
cation. 

[0046] In order to attend to the compatibility problem 

35 jn slave-to-slave communication within a piconet, the 
master unit could simply distribute the list of supported, 
and unsupported, features for a certain slave unit to- 
gether with the address information for the concerned 
slave unit. The list of features should first be obtained 

40 from the new slave unit by the master unit via the 
LMP_features_req LMP_features_res procedure, al- 
though the list of features must be extended to cover e. 
g. support for the shared medium emulation layer, e.g. 
the NAL layer, if used, forwarding capability, support for 

45 slave-to-slave intra-piconet communication, etc. 
Changes in the list of supported features in already ex- 
isting piconet members should also be communicated 
to the other piconet members. This could be done by 
first informing the master unit, unless the concerned unit 

50 itself is the master unit, which then distributes it to the 
other slave units using broadcast or multiple unicast 
messages. An alternative is that the concerned slave 
unit distributes the new list of supported, and unsupport- 
ed, features, or possibly just the modifications of the old 

55 list, to the other slaves using slave-to-slave communi- 
cation and to the master unit using slave-to-master uni- 
cast. 

[0047] In a yet further method for providing useful in- 
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formation, i.e. any of the above mentioned types of in- 
formation and possibly other useful information, to all 
the member units of a piconet is to store all the informa- 
tion in the master unit, e.g. a database, and making said 
information accessible on request from the slave units. 5 
A slave unit would then be able to request all the infor- 
mation in the database of the master or a relevant sub- 
set of said information from the master. A relevant sub- 
set would e.g. be all address information, all forwarding 
node information, or address information for a selected 
unit. 

[0048] The request and response could be carried by 
LMP or a specifically designated protocol or by different 
protocols, depending on the type of information that is 
requested. 

[0049] Before a slave unit can request any information 
from the master unit, the relevant information must be 
conveyed from the slave units to the master unit. This 
could be done on request from the master unit or trans- 
mitted from a slave unit triggered by an internal event in 
the slave unit, e.g. a switch from being a forwarding 
node to not being one. Such a "master unit database" 
method may be used as a stand-alone solution or as a 
back up mechanism for any of the distribution mecha- 
nisms described above. 

[0050] In another embodiment, a method for attend- 
ing to compatibility problems during slave-to-slave com- 
munication is to allow the LMP_features_req and 
LMP_features_res PDU to go slave-to-slave, i.e. essen- 
tially traversing two hops within a piconet. This method 
requires that both the involved slave units support slave- 
to-slave communication, but also other information of 
the support of other features, e.g. support of a the mod- 
ified Baseband packet header format described in the 
simultaneously filed patent application (Method, node 
and arrangement in a communication network) and dis- 
cussed in more detail in conjunction with Fig. 1a-e. 
[0051] In Fig. 6 a Bluetooth network or scatternet 601 
is illustrated comprising two piconets. The first piconet 
602 comprises multiple nodes A, B, C, D, E and F, the 
node F being the master and the other nodes A, B, C, 
D, E being slaves. The second piconet 603 comprises 
multiple nodes E, G, H, I and J, the node J being the 
master, and the other nodes E, G, H and I being slaves. 
The respective slaves A, B, C, D and E communicate 
with the master F over radio links 604. The respective 
slaves E, G, H and I are communicating with the master 
J over radio links 605. The unit E is a slave in both the 
first piconet 602 and in the second piconet 603 and acts 
as a forwarding node, when transferring packets be- 
tween the first piconet 602 and the second piconet 603. 
The Bluetooth network 601 thus comprises two masters 
F and J and one forwarding node E. Within the network, 
a Baseband packet is transferred, the Baseband packet 
having a header, as shown in Figs. 1a and 1b. The mas- 
ter F controls all the communication within the first pi- 
conet 602 and the master J controls all the communica- 
tion within the second piconet 603. A packet, also called 
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a Baseband packet as in slave-to-slave communication, 
may be routed from a first node A in the first piconet via 
the master F, the forwarding node E and the master J, 
to a second node G in the second piconet. To perform 
the transmission of the packet, a route is created be- 
tween the first node A and the second node G, each 
packet being sent along the route comprising routing in- 
formation, originating from the Network layer or NAL lay- 
er. When a routing protocol called AODV (Ad-Hoc On 
demand Distance Vector) is used, the routing informa- 
tion is the address of the destination node, in this case 
that of the second node G. When a routing protocol 
called Dynamic Source Routing is used, the routing in- 
formation comprises the address of each node to be tra- 
versed along the route and the destination address, 
which in this case comprise the addresses of the nodes 
F, E, J and G. In order to perform the packet transmis- 
sion using the Baseband protocol in the physical layer, 
the routing information is placed in a header of a lower 
protocol, i.e. in the payload header field implying a short- 
circuiting of both the Baseband payload sublayer and 
the L2CAP layer. The term short-circuiting a protocol 
layer as used herein means that the forwarding node 
and the master node does not have to unpack and an- 
alyze the information of said protocol layer, in order to 
forward the packet. 

[0052] In Fig. 7c a diagram of the Baseband packet 
header format is shown. In Fig. 7a the payload header 
format of a Baseband packet for single slot packets is 
shown. In Fig. 7b a diagram of the format for Baseband 
packets of multi-slot type is shown. The headers shown 
in Fig. 7a-c are, relatively the headers depicted in Fig. 
1c-e, enlarged by a forwarding indicator field FORW IND 
and a relevant routing indicator field ROUTING INFO. 
The forwarding indicator instructs a forwarding node 
that it should send the packets to the upper layer proto- 
cols, when the forwarding indicator is not set, e.g. 
FORW IND=0, or that it should invoke a forwarding proc- 
ess within the lower layer, when the forwarding indicator 
is set, e.g. FORW IND=1. The setting of the forwarding 
indicator also indicates that it is followed by the address 
information that is required to forward the packet. If the 
forwarding indicator is not set, no routing information is 
included. Alternatively, the routing information may be 
included, indicating to the receiving node that said re- 
ceiving node is the destination node and thus that the 
packet is to be sent to upper layer protocols. This low 
level routing method may be used for data packets being 
sent along an already established route. The message 
that was used to create the route in the first place, e.g. 
NAL or a Network layer message, cannot use the pro- 
cedure as described herein. 

[0053] Now, packet transmission the network layer, 
the packet may be much larger than in the physical layer. 
The NAL or Network layer packets will probably fit into 
a single L2CAP packet, but the L2CAP packets may of- 
ten have to be segmented before they are transferred 
in multiple Baseband packets. The fact that the routing 
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information is included in every Baseband packet, in- 
stead of only in the NAL or Network layer packet, in- 
creases the overhead. In one embodiment, a L2CAP 
packet is segmented into multiple Baseband packets to 
be transmitted, wherein a first Baseband packet com- 
prises the first segment of the L2CAP packet, and the 
subsequent Baseband packets comprise the respective 
subsequent segments of the L2CAP packet. In a further 
embodiment, the forwarding indicator is set, and routing 
information is inserted in the first and the subsequent 
Baseband packets. 

[0054] In a yet further embodiment, the forwarding in- 
dicator is set and the routing information is inserted only 
in the first Baseband packet, but in the subsequent 
Baseband packets no routing information is included. In 
this case, the forwarding indicator within the first Base- 
band packet also instructs the forwarding node E and 
the masters F and J (as shown in Fig. 6) to store the 
routing information of the first Baseband packet and as- 
sociate the routing information with the incoming link, i. 
e. the link on which the first Baseband packet is received 
by the forwarding node E and on which also the subse- 
quent Baseband packets will be received by the for- 
warding node E. The forwarding indicator has to be com- 
plemented with yet a one-bit indicator, which is called 
Routing Information Indicator (Rll). The Rll is set only 
when the forwarding indicator is set. The purpose of the 
Rll is to indicate whether the routing information is ac- 
tually included after the forwarding indicator. For the first 
Baseband packet the Rll packet is set e.g. = 1 , indicating 
that the routing information is present. In the subsequent 
respectively Baseband packets the forwarding bit is set, 
the Rll is cleared, e.g. = 0, indicating that no routing in- 
formation is present. Then, the forwarding node E, and 
the master nodes F and J, use the latest received routing 
information to forward the subsequently received Base- 
band packets, until new routing information is received 
in a Baseband packet. 

[0055] In Fig. 9 is a flowchart illustrating how a packet 
is routed from a first node A in a first piconet via a for- 
warding node E to a second node G in a second different 
piconet in the physical layer using the Bluetooth protocol 
of a Bluetooth network comprising multiple nodes. In 
block 901, the first node A indicates in a header of a 
Baseband packet that the packet should be forwarded. 
Thereafter, in block 902, the first node A inserts relevant 
information in the header of the Baseband packet. Then, 
in block 903, the first node transmits the packet using 
slave-to-slave communication to the forwarding node E. 
Thereafter, in block 904, the forwarding node E analyses 
the forwarding indication and the routing information of 
the received Baseband packet. Then, in block 905, the 
forwarding node E short-circuits the Logical Link Control 
and Adaptation Layer Protocol (L2CAP) layer of the 
packet. Finally, in block 906, the forwarding node E for- 
wards the packet to the destination node, i.e. the second 
node G, according to the received routing information, 
using slave-to-slave communication. 



[0056] Now a process illustrating how a node be- 
comes a forwarding node will be described. First, the 
information flow in the first piconet will be described with 
reference to the flowchart in Fig. 11 . Two cases must be 

5 considered; the considered Bluetooth unit may be a 
slave unit or a master unit of the first piconet. In block 
1510 a Bluetooth unit A is a member of a first piconet. 
Then, in block 1520, said unit A joins a second piconet 
using the INQUIRY and PAGE procedures, specified in 

10 the Bluetooth standard, in block 1530 it is checked 
whether the unit A is the master of the first piconet. If 
the unit A is the master of the first piconet, the flow pro- 
ceeds directly to block 1 550. If the unit A is not the mas- 
ter of the first piconet, the flow goes to block 1540. In 

is block 1540 the unit A informs the master of the first pi- 
conet of its new forwarding node status, optionally in- 
cluding other information, such as the BD_ADDR of the 
master of the second piconet, the master clock value 
and scheduling parameters of the second piconet. 

20 Then, in block 1550 the master unit of the first piconet 
enters data concerning unit A in its list of forwarding 
nodes in the piconet, including e.g. the AM_ADDR and 
BD_ADDR of unit A and other optional information. 
Thereafter, in block 1560, the master unit of the first pi- 

25 conet transmits information about the new forwarding 
node, all the information being stored in the master unit, 
or a subset thereof, to the at least one of the slave units, 
except unit A, when unit A is a slave unit in the first pi- 
conet and unless the intra-piconet broadcast mecha- 

30 nism is used to convey the information. Finally, the flow 
goes to block 1570. In block 1570 each receiving slave 
unit inserts the received forwarding node information in 
its list of forwarding nodes in the piconet, of which the 
receiving slave unit is a member. 

35 [0057] Now the information flow in the second piconet 
when a node becomes a forwarding node will be dis- 
closed. There are two cases having two alternative ways 
to distribute information in the piconet, resulting in four 
different cases: 

40 

• The new unit is a slave in the second piconet 

Case 1 : First the piconet member information 
is distributed, thereafter, the forwarding node 
45 information is distributed. 

Case 2: Piconet member information and for- 
warding node information are distributed to- 
gether. 

50 • The new unit is the master of the second piconet, i. 
e. the second piconet was just created. 

Case 3: First, the piconet member information 
is distributed, thereafter, the forwarding node 
55 information is distributed. 

Case 4: Piconet member information and for- 
warding node information are distributed to- 
gether 
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[0058] The cases 1 and 3 will now be disclosed with 
reference to the flowchart in Fig. 12a and Fig. 12b. In 
block 2100 of Fig. 12a, a Bluetooth unit A is a member 
of a first piconet. Then, in block 2110 the unit A joins a 
second piconet using the INQUIRY and PAGE proce- 
dures specified in the Bluetooth standard. In block 2115 
it is determined whether the unit A is a master of the 
second piconet. If the unit A is the master of the second 
piconet, the BD_ADDR of unit A is already known to the 
at least one slave unit of the second piconet. Since unit 
A is the master unit, it has no AM_ADDR. Thus, when 
unit A is the master of the second piconet, the flow pro- 
ceeds to block 21 20, in which other relevant information, 
e.g. compatibility information such as a list of supported 
and unsupported features, IP address, etc. is transmit- 
ted to the at least one slave unit of the second piconet. 
Thereafter, the flow goes to Fig 12b t which will be dis- 
cussed below. When the unit A is a slave unit of the sec- 
ond piconet, the flow goes from block 2115 to 2125. 
When the unit A is a slave unit of the second piconet, 
the BD_ADDR and the AM_ADDR of unit A is already 
known to the master of the second piconet. In block 
2125, other relevant information, e.g. compatibility infor- 
mation such as a list of supported and unsupported fea- 
tures, IP address, etc. is transmitted from unit A to the 
master unit of the second piconet. Thereafter, the flow 
goes to block 21 30. In block 2130 the master unit of the 
second piconet stores the received information in its da- 
tabase, preferably in its list of piconet members. Then, 
in block 2135 the master unit of the second piconet 
sends BD_ADDR and AM_ADDR of each of the other 
slave units in the second piconet, information which it 
has previously received from each of the other slave 
units in the second piconet, entirely or a subset thereof, 
and the corresponding information on the master unit of 
the second piconet, excluding BD_ADDR, which is al- 
ready known to unit A, and the AM_ADDR, which does 
not exist, to unit A. Together with the above information, 
or as a separate transmission , the master of the second 
piconet also sends information about the forwarding 
nodes in the second piconet to unit A. Then, in block 
2140 unit A inserts a new record having relevant data 
for each of the other slave units in the second piconet 
in its database, preferably in its list of piconet members. 
The received information about the master unit of the 
second piconet is also stored in the list of piconet mem- 
bers, or elsewhere in the database. Thereafter the flow 
go to block 2145 in which unit A inserts a new record 
having relevant data for each of the other forwarding 
nodes in the second piconet in its database, preferably 
in the list of forwarding nodes in the piconet, including 
in each record, e.g. BD_ADDR, and the AM_ADDR, 
when present, of the forwarding node and other optional 
information. Then, in block 2150 the master unit of the 
second piconet sends the BD_ADDR and the 
AM_ADDR of unit A and the information which it re- 
ceived from unit A, entirely or a subset thereof, to the 
other at least one slave unit in the second piconet, i.e. 



excluding unit A, unless the intra-piconet broadcast 
mechanism is used to convey the information. Thereaf- 
ter the flow goes to block 2155 in which each receiving 
slave unit inserts a new record having relevant data con- 

5 cerning unit A in its database, preferably in its list of pi- 
conet members. Then, in block 2160 the unit A delivers 
information about its forwarding node status to the mas- 
ter unit of the second piconet. Thereafter, in block 2165 
the master unit of the second piconet inserts a record 

10 concerning unit A in its list of forwarding nodes in the 
piconet, comprising e.g. the AM_ADDR and the 
BD_ADDR of unit A and other optional information. 
Then, in block 2170 the master unit of the first piconet 
transmits information concerning the new forwarding 

15 node, all the information stored in the master unit or a 
subset thereof, to the at least one slave unit, except unit 
A, when unit A is a slave unit of the first piconet, and 
unless the intra-piconet broadcast mechanism is used 
to convey information. Finally, in block 2175 each re- 

20 ceiving slave unit inserts the received forwarding node 
information in its list of forwarding nodes in the piconet. 
[0059] Fig. 12b discloses the continued information 
flow, after block 2120. The BD_ADDR and the 
AM_ADDR of each of the slave units in the second pi- 

25 conet is already known to unit A, since unit A is the mas- 
ter unit of the second piconet, and in a block 2180 unit 
A collects other information relevant to the slaves, if any, 
e.g. compatibility information, such as a list of supported 
and unsupported features. When a slave unit is a for- 

30 warding node, the forwarding node status and optional 
related information is also transferred to and collected 
by unit A. Then, in block 2182 unit A inserts the received 
information in the already existing records in its list of 
piconet members. Thereafter, in block 2184 unit A in- 

35 serts information of each slave unit which is a forwarding 
node, in its list of forwarding nodes in the piconet, the 
information comprising e.g. AM_ADDR and the 
BD_ADDR and other optional information. The 
BD_ADDR of unit A is already known to the slave units 

40 of the second piconet and since unit A is the master unit, 
it has no AM_ADDR, but in the next block, other relevant 
information is transmitted to the at least one slave units 
of the second piconet, e.g. compatibility information, 
such as a list of supported and unsupported features, 

45 |p addresses, etc. Then in block 2190, each receiving 
slave unit stores the relevant data concerning unit A in 
its database, e.g. in its list of piconet members. Then, 
in block 2192, unit A sends information concerning its 
forwarding node status to the at least one slave units of 

50 the second piconet. Finally, in block 2194, each receiv- 
ing slave unit inserts the received forwarding node in- 
formation in its list of forwarding nodes in the piconet, 
including e.g. the BD_ADDR and other optional infor- 
mation. 

55 [0060] The cases 2 and 4 will now be discussed with 
reference to the flowchart in Fig. 13a and Fig. 13b. In 
block 5500, Fig. 13a, a Bluetooth unit A is a member of 
a first piconet. Then, in block 5510 said unit A joins a 
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second piconet using the INQUIRY and PAGE proce- 
dures being specified in the Bluetooth specification. In 
block 5520 it is determined whether the unit A is a mas- 
ter of the second piconet. If the unit A is the master of 
the second piconet, the flow goes to Fig 13b, which will 
be discussed below. In the case where the unit A is a 
slave unit of the second piconet, the flow goes from 
block 5520 to 5530. When the unit A is a slave unit of 
the second piconet, the BD_ADDR and the AM_ADDR 
of unit A are already known to the master of the second 
piconet. In block 5530 other relevant information, e.g. 
compatibility information such as a list of supported and 
unsupported features, IP address, etc., is transmitted to- 
gether with information concerning the forwarding node 
status of unit A, from unit A to the master unit of the 
second piconet. Thereafter, the flow goes to block 5535. 
In block 5535, the master unit of the second piconet 
stores the received information in its database. Prefer- 
ably, part of the information, e.g. excluding the informa- 
tion concerning the forwarding status of unit A, is stored 
in the list of piconet members and the information con- 
cerning the forwarding node status of unit A, together 
with e.g. BD_ADDR and AM_ADDR of unit A is entered 
in the list of forwarding nodes. Then, in block 5540 the 
master unit of the second piconet sends BD_ADDR and 
AM_ADDR of each of the other slave units in the second 
piconet, the information which it has previously received 
from each of the other slave units in the second piconet, 
entirely or a subset thereof, and the corresponding in- 
formation about the master unit of the second piconet, 
excluding BD_ADDR, which is already known to unit A, 
and the AM_ADDR, which does not exist, to unit A. To- 
gether with the above mentioned information, or as a 
separate transmission, the master of the second piconet 
also sends information about the forwarding nodes in 
the second piconet to unit A. Then, in block 5545 unit A 
inserts a new record having relevant data for each of the 
other slave units in the second piconet in its database, 
preferably in its list of piconet members. The received 
information about the master unit of the second piconet 
is also stored in the list of piconet members, or else- 
where in the database. Thereafter, the flow goes to block 
5550, wherein unit A inserts a new record with relevant 
data for each of the other forwarding nodes in the sec- 
ond piconet in its database, preferably in the list of for- 
warding nodes in the piconet, including in each record, 
e.g. BD_ADDR, and the AM_ADDR, when present, of 
the forwarding node and other optional information. 
Then, in block 5555, the master unit of the second pi- 
conet sends the BD_ADDR and the AM_ADDR of unit 
A and the information which it received from unit A, en- 
tirely or a subset thereof, to the other at least one slave 
unit in the second piconet, i.e. excluding unit A unless 
the intra-piconet broadcast mechanism is used to con- 
vey the information. Finally, the flow go to block 5560, 
wherein each receiving slave unit stores all or parts of 
the received data in its database. Preferably part of the 
data, e.g. excluding the data concerning the forwarding 



node status of unit A, is inserted in the list of piconet 
members. The data concerning the forwarding node sta- 
tus of unit A, together with e.g. the BD_ADDR and 
AM_ADDR of unit A is inserted in the list of forwarding 
5 nodes. 

[0061] Fig. 13b discloses the information flow, in the 
case where unit A is a master, after block 5520 in Fig 
13a. The BD_ADDR and the AM_ADDR of each of the 
slave units in the second piconet are already known to 
unit A, since unit A is the master unit of the second pi- 
conet. Thus, in block 5560, unit A collects other relevant 
information, if any, e.g. compatibility information, such 
as a list of supported and unsupported features. When 
a slave unit is a forwarding node, the forwarding node 
status and optional related information is also trans- 
ferred to unit A. Then in block 5562, unit A inserts the 
received information in the already existing records in 
its list of piconet members. Thereafter, in block 5564, 
unit A inserts information of the possibly at least one 
slave units being forwarding nodes in its list of forward- 
ing nodes in the piconet, comprising e.g. AM_ADDR and 
the BD_ADDR and other optional information. The 
BD_ADDR of unit A is already known to the slave units 
of the second piconet and since unit A is the master unit, 
it has no AM_ADDR. Thus, in block 5560 other relevant 
information is transmitted to the at least one slave unit 
of the second piconet, e.g. compatibility information, 
such as list of supported and unsupported features, IP 
address, etc. Then in block 5570, each receiving slave 
unit stores the relevant data concerning unit A in its da- 
tabase, e.g. in its list of piconet members. Then, in block 
5572, each receiving slave unit inserts the received for- 
warding node information in its list of forwarding nodes 
in the piconet, including e.g. the BD_ADDR and other 
optional information. 

[0062] The scenario when a Bluetooth unit ceases to 
be a forwarding node will now be considered. A Blue- 
tooth unit A is assumed to be a member of a first and a 
second piconet and thus constitutes a forwarding node 
in both piconets. Unit A then leaves the second piconet. 
Fig. 14 is a flowchart illustrating the information flow in 
the first piconet when a unit A ceases to be a forwarding 
node. There are two cases to consider: 

• Unit A is a slave unit in the first piconet 

• Unit A is the master of the first piconet 

[0063] In Fig 14, as stated in block 4100, unit A is a 
member of a first and a second piconet. Then, the flow 
goes to block 41 1 0, wherein the unit A leaves the second 
piconet, in accordance with known procedures specified 
in the Bluetooth standard, either explicitly, by sending 
or receiving the LMP PDU LMP_detach, or implicitly by 
connection time-out due to loss of radio contact. Then 
in block 41 20, it is decided whether the unit A is the mas- 
ter of the first piconet. If unit A is the master the flow 
goes to block 41 30. If the unit A is a slave unit in the first 
piconet, the unit A sends a message to the master unit 
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of the first piconet, indicating that unit A is no longer a 
forwarding node. If unit A is present in its own list of for- 
warding nodes, then the record comprising unit A is re- 
moved from this list. Then, in block 41 30, the master unit 
of the first piconet removes the record comprising unit 
A from its list of forwarding nodes. Thereafter, in block 
4135, the master unit of the first piconet informs the at 
least one slave units of the first piconet, excluding A 
when unit A is a slave unit of the first piconet and unless 
the intra-piconet broadcast mechanism is used to con- 
vey the information, that unit A has ceased to be a for- 
warding node. Finally, in block 4140, each receiving 
slave unit removes the record comprising unit A from its 
list of forwarding nodes. 

[0064] Now the information flow when a Bluetooth unit 
ceases to be a forwarding node in the second piconet 
will be disclosed with reference to Figs. 15a and 15b. 
There are two cases to be considered: 

Case 1 : First, the indication that unit A has ceased 
to be a forwarding node is distributed, thereafter the 
indication that unit A has left piconet is distributed. 
Case 2: Only the indication that unit A has ceased 
to be a forwarding node is distributed. The fact that 
unit A can no longer be a forwarding node in the 
piconet is assumed implicitly. 

[0065] The trivial cases, where unit A is the master of 
the second piconet, in which case the second piconet 
breaks down when the master unit leaves, and where 
the second piconet comprises only one unit apart from 
unit A, in which case there are no other units to which 
information is to be distributed are not described in de- 
tail. 

[0066] Now, the first case will be described with refer- 
ence to Fig. 15a. First, as stated in block 7100, a unit A 
is assumed to be a member of a first and a second pi- 
conet, the unit A being a slave unit in the second piconet. 
Then, in block 7110, the unit A leaves the second pi- 
conet, in accordance with procedures specified in the 
Bluetooth standard, either explicitly, by sending or re- 
ceiving the LMP PDU LMP_detach, or implicitly by con- 
nection time-out due to loss of radio contact. Thereafter, 
in block 71 1 5, the master unit of the second piconet de- 
tects that the unit A has left the second piconet, using 
known mechanism specified in the Bluetooth standard. 
Then, in block 7120, the master unit of the second pi- 
conet removes the record comprising unit A from its list 
of forwarding nodes. In block 7125, the master unit of 
the second piconet informs the at least one slave unit of 
the second piconet that unit A has ceased to be a for- 
warding node. Then, in block 7130, each slave unit re- 
moves the record comprising unit A from its list of for- 
warding nodes. In block 7140, the master unit of the sec- 
ond piconet removes the record comprising unit A from 
its list of piconet members. Thereafter, in block 7145, 
the master unit of the second piconet informs the at least 
one slave unit of the second piconet that unit A has left 



the piconet. Finally, in block 7150, each receiving slave 
unit removes the record comprising the unit A from its 
list of piconet members. 

[0067] Now, the second case will be disclosed with 
5 reference to Fig. 15b. First, in block 7200, a unit A is a 
member of a first and a second piconet, the unit A being 
a slave unit in the second piconet. Then, in block 7210, 
the unit A leaves the second piconet, in accordance with 
procedures specified in the Bluetooth standard, either 
10 explicitly, by sending or receiving the LMP PDU 
LMP_detach, or implicitly by connection time-out due to 
loss of radio contact. Thereafter, in block 7220, the mas- 
ter unit of the second piconet detects that the unit A has 
left the second piconet, using known mechanism spec- 
*5 ified in the Bluetooth standard. Then, in block 7230, the 
master unit of the second piconet checks whether unit 
A was included in the list of forwarding nodes and re- 
moves the record comprising unit A from its list of for- 
warding nodes. In block 7240, the master unit of the sec- 
20 ond piconet removes the record comprising unit A from 
its list of piconet members. In block 7250, the master 
unit of the second piconet informs the at least one slave 
units of the second piconet that unit A has left the pi- 
conet. In block 7260, each receiving slave unit checks 
25 whether unit A was included in the list of forwarding 
nodes and then removes the record comprising unit A 
from its list of forwarding nodes. Finally, in block 7270, 
each receiving slave unit removes the record compris- 
ing unit A from its list of piconet members. 
30 [0068] The invention being thus described, it will be 
obvious that the same may be varied in many ways. 
Such variations are not to be regarded as a departure 
from the spirit and scope of the invention, and all such 
modifications as would be obvious to one skilled in the 
35 art are intended to be included within the scope of the 
following claims. 

Claims 

40 

1. A digital communication system comprising nodes, 
the nodes including a central node and at least two 
peripheral nodes, the central node comprising all 
means for the communication in the system and a 
45 memory for storing information related to the sys- 
tem itself and/or the individual nodes, the nodes 
each comprising a transmitter and a receiver, and 
information only being directly transferred between 
the central node and each of the peripheral nodes, 
so characterized by control means in the central node 
for transferring information stored in the memory 
means related to the system and/or the individual 
nodes to every peripheral node. 

55 2. A digital communication system according to claim 
1, characterized in that each peripheral node com- 
prises means for storing said information. 
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3. A digital communication system according to claim 
1 , characterized in that the direct transferring of in- 
formation is made wireless, in particular using short 
range radio waves. 

4. A digital communication system according to claim 
1 , characterized in that the control means in the 
central node are arranged to transfer address infor- 
mation comprising at least one address of each of 
the peripheral nodes. 

5. A digital communication system according to claim 
1, characterized in that the control means in the 
central node are arranged to transfer compatibility 
related information. 

6. A digital communication system according to claim 
1, characterized in that the system is a Bluetooth 
piconet. 

7. A digital communication system according to claim 
1 , characterized in that a first one of the nodes is 
a central node of a first group of the nodes and a 
second one of the nodes is a central node of a sec- 
ond group of the nodes, the first and second nodes 
being different nodes and the nodes being capable 
of being members in both the first and second 
group, each node having first memory means for 
storing information relating to information on the 
first one of the nodes and on the nodes of the first 
group and second memory means for storing infor- 
mation relating to information on the second one of 
the nodes and on the nodes of the second group. 

8. A digital communication system according to claim 
7, characterized in that the nodes have control units 
connected to the transmitters and receivers for 
transferring to a central node information on a 
change of a node to being or to finishing being a 
member in both the first and second groups. 

9. A method in a digital communication system com- 
prising nodes, the nodes including a central node 
and at least two peripheral nodes, information only 
being directly transferred between the central node 
and each of the peripheral nodes, the central node 
controlling all the communication in the system, and 
information related to the system itself and/or the 
individual nodes being stored in the central node, 
characterized in that information related to the sys- 
tem and/or the nodes is transferred to every periph- 
eral node. 

10. A method according to claim 9, characterized in 
that part of said information transferred to every pe- 
ripheral node is derived from information conveyed 
from the peripheral nodes to the central node when 
requested by the central node. 
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11. A method according to claim 9, characterized in 
that part of said information transferred to every pe- 
ripheral node is derived from information conveyed 
from the peripheral nodes to the central node initi- 

5 ated by the peripheral nodes in particular triggered 
by an event in the respective peripheral node. 

12. A method according to claim 9, characterized in 
that said information is, entirely or in part, address 

10 information comprising an address of each of the 
peripheral nodes. 

13. A method according to claim 9, characterized in 
that said information is, entirely or in part, compat- 

15 jbility related information. 

14. A method according to claim 9, characterized in 
that all direct transfer of information is made wire- 
lessly, in particular using short range radio waves. 

20 

15. A method according to claim 9, characterized in 
that the digital communication system is a Bluetooth 
piconet. 

25 16. A method according to any of claim 9-15, charac- 
terized in that the transferring of said information is 
performed using a Bluetooth broadcast mecha- 
nism. 

30 17. A method according to any of claim 9-15, charac- 
terized in that the transferring of said information is 
performed using the Bluetooth unicast system to 
each peripheral node in turn. 

35 18. A method according to any of claim 9-17, charac- 
terized in that the transferring of said information is 
made using the Bluetooth LMP protocol. 

19. A method according to any of claim 9-17, charac- 
*o terized in that the transferring of said information is 

made using a protocol layer between the L2CAP 
and the network layer, said protocol layer emulating 
a shared medium network towards the network lay- 
er. 

45 

20. A method according to any of claim 13-19, charac- 
terized in that the transferring of said information is 
made when a new peripheral node joins the digital 
communication system. 

50 

21. A method according to any of claim 13-20, charac- 
terized in that, when a new peripheral node joins 
the system, the part of said information related to 
all the other peripheral nodes is transferred from the 

55 central node to said new peripheral node. 

22. A method according to any of claim 9-20, charac- 
terized in that a message is transferred from the 
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central node to all the peripheral nodes when one 
of the peripheral nodes has left the system. 

23. A method according to claim 9, wherein a first one 

of the nodes is a master node of a first group of the 5 
nodes, a second one of the nodes is a master node 
of a second group of the nodes, the first and second 
ones of the nodes being different nodes and the 
group of first nodes and the group of second nodes 
together with the second one of the nodes having a 10 
node in common, this node being a forwarding 
node, characterized in that when a node changes 
from being a forwarding node to not being a for- 
warding node, or vice versa, a message is sent to 
all the nodes in the first and second groups except 15 
the node itself. 

24. A method according to claim 23, characterized in 
that the message is sent from the master nodes of 
the first and second groups. 20 

25. A method according to claim 23, characterized in 
that the message is sent from the node itself. 

26. A method according to claim 23, characterized in 25 
that before sending the message, information of the 
change of forwarding node status in the node is 
transferred from the node to the master node of the 
first group, and to the master node of the second 
group, provided that the node is not the master node 30 
of the second group. 
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^ was included in the list of forwarding nodes and 
"~M*hen removes the record comprising unit A from 
its list of piconet members 
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Each receiving slave unit removes the record 
comprising unit A from its list of piconet members 



Fig. 15b 
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Description 

FIELD OF INVENTION 

[0001] The present invention relates to a method and 
arrangement in a digital communication system consti- 
tuting a network of multiple nodes. More specifically the 
present invention relates to a method and an arrange- 
ment for providing distribution within a Piconet using 
short range radio technology. 

DESCRIPTION OF RELATED ART 

[0002] The Bluetooth interface is an example of a 
short-range radio interface, which was originally intend- 
ed as a replacement for cables between electrical de- 
vices. The term Bluetooth is in this disclosure used as 
an example of usage of short-range radio communica- 
tion. Printers, digital cameras, telephones, laptop com- 
puters, video monitors, electronic calendars (PDA), 
desktops, fax machines, keyboards, joysticks as well as 
ordinary computers and virtually any other digital device 
can be part of such a short-range radio system, i.e. any 
of these devices could have a Bluetooth radio chip and 
the software required therefore. But beyond untethering 
devices by replacing cables, short range radio commu- 
nication can provide a universal bridge to existing data 
networks, as a peripheral interface. It can also be used 
to form small private ad hoc groupings of interconnected 
devices away from fixed network infrastructures or con- 
nected to a fixed network infrastructure via a gateway. 
The Bluetooth radio communication system is designed 
to operate in a noisy radio frequency environment and 
uses therefore a fast acknowledgement and frequency 
hopping scheme to make the links between the units in 
the system robust. Thus, Bluetooth radio modules avoid 
interference from other signals by hopping to a new fre- 
quency after transmitting or receiving a data packet, as 
is illustrated in Fig. 5. Compared to other systems oper- 
ating in the same frequency band, the Bluetooth radio 
communication system typically hops faster and uses 
shorter data packets. This makes the Bluetooth radio 
communication system more robust than other systems. 
Use of Forward Error Correction (FEC) limits the impact 
of random noise on long-distance links between units in 
the system. 

[0003] A Bluetooth radio communication system uses 
a frequency hopping scheme within the unlicensed ISM 
(Industrial, Scientific, Medical) band at 2.4 GHz. A fre- 
quency hop transceiver is used in the units to reduce 
the influence of interference and fading. A shaped, bi- 
nary FM modulation scheme is used to minimize the 
complexity of the transceiver. The gross data rate is 
1Mb/s and a TDD (Time-Division Duplex) scheme is 
used for full-duplex transmission. 
[0004] The Bluetooth base band protocol is a combi- 
nation of circuit and packet switching, as is shown in Fig. 
5. In Fig. 5, si denotes a single time slot, and p1 denotes 



a packet the transmission of which requires three time 
slots. The packets are normally transmitted using differ- 
ent hop frequencies. A packet is nominally transmitted 
in a single slot, but a single packet can require up to five 

5 slots. Bluetooth can support an asynchronous data 
channel, up to three simultaneous synchronous voice 
channels, or a channel, that simultaneously supports 
asynchronous data and synchronous voice. Each voice 
channel supports a 64 kb/s synchronous (voice) link. 

10 The asynchronous channel can support an asymmetric 
link of maximally 721 kb/s in either direction while per- 
mitting 57.6 kb/s in the return direction, or a 432.6 kb/s 
symmetric link. 

[0005] In Fig. 2, function blocks of a unit having a 
15 short-range radio transceiver, such as Bluetooth, are 
shown. A radio unit 300 provided with an antenna is con- 
nected to a link control unit 31 0 providing the base band. 
The link control unit 310 is connected to the Central 
Processing Unit, called CPU, 320 providing the link 
20 management. The CPU is connected to a memory 360 
storing the software and consisting of two memory units: 
an SRAM 330 and a FLASH memory 340. The CPU 320 
is connected to a host interface 350. An SRAM is a fast 
temporary memory. A FLASH memory is programmable 
25 ROM. 

[0006] Fig. 8 shows two piconets A1 and B1 in a scat- 
ternet. The piconet A1 comprises four units 10, 20, 30, 
40; and the piconet B1 comprises three units 40, 50 and 
60. In the piconet A1, the unit 10 is a master unit. The 

30 unit 40 is a member of both piconet A1 and piconet B1 . 
Two or more Bluetooth units (BT) using Bluetooth for 
communication with each other and sharing the same 
channel (i.e. the same frequency hop sequence and 
time slot synchronization) form a piconet, i.e. a piconet 

35 is a collection of units interconnected using Bluetooth in 
an ad hoc fashion. Within a piconet a Bluetooth unit can 
have either of two roles: it can be a master or a slave. 
Within each piconet there is one and only one master, 
and up to seven active slaves can be connected, i.e. a 

40 piconet starts with two interconnected units, such as 
portable PC and a cellular telephone, and it may grow 
to eight interconnected units. All Bluetooth units are 
peer units and basically have identical implementations. 
Any BT unit can become the master in a piconet. How- 

45 ever, when a piconet is being formed, one unit will take 
the role of the master and the other(s) will be slave(s) 
for the duration of the piconet. A scatternet, or an ad hoc 
network, is a network comprising multiple independent 
and non-synchronized piconets. The master or master 

so unit is the unit in a piconet the clock and hopping se- 
quence of which are used to synchronize all other units 
in the piconet. A slave or slave unit is every unit in a 
piconet that is not the master in the piconet. Two or more 
piconets can be interconnected, forming a scatternet as 

55 has already been defined. The connection point be- 
tween two piconets consists of a single BT unit that is a 
member of both piconets. A BT unit can simultaneously 
be a slave of a plurality of piconets, but only master in 
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one piconet. I.e., a BT unit functioning as master in one 
piconet can act as a slave in another piconet or piconets. 
A BT unit can only transmit and receive data in one pi- 
conet at a time, so participation in multiple piconets has 
to be on a time division multiplex basis. The Bluetooth 
system supports both point-to-point and point-to-multi- 
point connections. Several piconets can be linked to- 
gether ad hoc, where each piconet is identified by a dif- 
ferent frequency hopping sequence. All units participat- 
ing in a same piconet are synchronized to the hopping 
sequence of the piconet. The scatternet topology can 
best be described as a multiple piconet structure, see 
Fig. 8. However, Bluetooth units for use in scatternets 
are not yet commercially available. 
[0007] Fig. 3a shows a Personal Digital Assistant 
PDA 500 utilizing an "add-on" Bluetooth communication 
device 510. The Bluetooth communication unit 510, 
which is provided with an antenna, is inserted in a slot 
in the PDA. The Bluetooth communication unit may be 
a PC-card or a compact flashcard provided with a Blue- 
tooth chipset. 

[0008] Fig. 3b shows a PDA utilizing a "built-in" Blue- 
tooth communication device. Here, the PDA is provided 
with an antenna. 

[0009] Fig. 3c shows a mobile telephone utilizing a 
"built-in" Bluetooth communication device, the Blue- 
tooth transceiver having an antenna, not shown, differ- 
ent from that of the mobile telephone. 
[0010] A Bluetooth system provides, as already told, 
full-duplex transmission built on slotted Time Division 
Duplex (TDD). Each slot used has a length of 0.625 ms. 
The time slots are numbered sequentially using a very 
large number range (the range is cyclic having a cycle 
of 2 27 ). Transmission from master to slave always starts 
in an even-numbered time slot whereas transmission 
from slave to master always starts in an odd-numbered 
time slot. The term "frame" as used here is defined as 
the combination of an even numbered time slot and the 
subsequent odd numbered time slot (i.e. a master-to- 
slave time slot and a slave-to-master time slot), except 
when multi-slot packets are used, and then other con- 
ventions are used. In a communication system using 
Bluetooth no direct transmission exists between slaves 
in a piconet. 

[001 1] The communication between the units of a pi- 
conet is organized such that the master polls each slave 
according to some polling scheme. With one exception 
a slave is only allowed to transmit after having been 
polled by the master. The slave will then start its trans- 
mission in the slave-to-master time slot immediately fol- 
lowing the packet received from the master. The master 
may or may not include data, e.g. payload data, in the 
packets used to poll the slave. The only exception to the 
above principle is that when a slave has an established 
SCO (Synchronous Connection-Oriented) link to the 
master, it is always allowed to transmit in a pre-allocated 
slave-to-master slot, even if not explicitly polled by the 
master in the directly preceding master-to slave slot. 



SCO links support real time voice traffic using reserved 
bandwidth. 

[0012] Each BT unit has a globally unique 48 bit ad- 
dress. This address, the Bluetooth Device Address 
5 (BDADDR) is assigned when the BT unit is manufac- 
tured and it is never changed. In addition thereto, the 
master of a piconet assigns a local Active Member Ad- 
dress (AMADDR) to each active slave of the piconet. 
The AM ADDR is only three bits long and is unique only 
10 within a~single piconet. The master uses the AMADDR 
when polling a slave in a piconet. When the slave, trig- 
gered by a packet received from the master and ad- 
dressed using the AM_ADDR of the slave, transmits a 
packet to the master, it includes its own AM_ADDR in 
*5 the header of the packet. 

[001 3] The packets can carry both synchronous data, 
on Synchronous Connection Oriented (SCO) links, and 
asynchronous data, on Asynchronous Connection-Less 
(ACL) links. For some types of packet used, an acknowl- 
edgment and retransmission scheme is used to ensure 
reliable transfer of data. Such a scheme is not used for 
SCO packets transferring synchronous data. Also for- 
ward error correction (FEC) in the form of channel cod- 
ing can be used. 

[0014] The standard format of a Bluetooth Baseband 
packet is shown in Fig. 1a. It comprises a field for an 
access Code, a header field and a payload field. The 
Fig. 1c illustrates the format of the header field, which 
comprises an AM_ADDR field, followed by a TYPE field, 
indicating the type of packet. The FLOW field encom- 
passes one bit used for flow control. The fields ARQN 
and SEQN control the acknowledgement and retrans- 
mission scheme. The Header Error check (HEC) field 
has information for checking the integrity of the header. 
In receiving a packet and using the information in the 
HEC field for checking the header field. The header field 
can be found to be in error and then the packet is dis- 
carded. Otherwise the packet is retained and further 
checks can be made. The format of the payload de- 
pends on the type of packet being transferred. An SCO 
packet is a packet transported on an SCO link and an 
ACL packet is a packet transferred on an ACL link. The 
payload field of a SCO packet comprises only a data 
field. The payload of an ACL packet, which is shown in 
Fig. 1 b, comprises a header field, a data field and, a field 
carrying information for cyclic redundancy check (CRC). 
In addition, there are hybrid packet including two data 
fields, one for synchronous data and one for asynchro- 
nous data. Hybrid packets are used when voice infor- 
mation and data are transmitted over the same link. 
Packets having a payload field and not provided with a 
CRC field are neither acknowledged nor retransmitted. 
There are two different formats of the payload header 
field. In Fig. 1d the format of the payload header field 
for single-slot packets is illustrated. In Fig. 1e is illustrat- 
ed the format of the payload header field for multi-slot 
packets. L_CH is a two bit field indicating the type of 
payload. L_CH=00 means that the "00" value is unde- 
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fined, and will therefore not be used. L_CH=01 indicates 
a continuation fragment of an L2CAP message to be de- 
scribed below. L_CH=01 indicates the start. of a L2CAP 
message or no fragmentation. Fragmentation means 
that the L2CAP packet is to large to be carried by a sin- 
gle Basband packet and therefore it has been split into 
multiple parts, so-called fragments, each fragment be- 
ing carried by a single Baseband packet. At the desti- 
nation node the fragments are reassembled into a com- 
plete L2CAP packet. L_CH=11 indicates an LMP mes- 
sage. The FLOW field is used for flow control. The 
FLOW bit in the header field is used for flow control at 
the L2CAP level. FLOW=0 indicates "stop transmis- 
sion". FLOW=1 indicates "ready for transmission". The 
FLOW bit in the last correctly received payload header 
determines the flow status. The LENGTH field indicates 
the length of the data field. Since multi-slot packets can 
carry a longer data field, the LENGTH field of the multi- 
slot payload header (Fig. 1e) is longer (not shown in the 
figure) than the LENGTH field of the single-slot payload 
header (Fig. 1d). As is shown in Fig. 1e, the payload 
header field of a multi-slot packet, the four last bits are 
undefined. 

[001 5] In a Bluetooth system a few protocol layers are 
used which are illustrated in Fig. 4 and comprise the 
Baseband (BB), protocol between the physical layer 103 
and the data link layer 104, the Link Manager Protocol 
(LMP) and the Logical Link Control and Adaptation Lay- 
er Protocol (L2CAP)in the data link layer 104. Also a 
"High level protocol or application" layer (106) may or 
may not be provided as well as a Network layer (105) 
is. In addition, a Network Adaptation Layer (NAL), not 
shown, residing between the data link layer (104) and 
the network layer (105) can be provided. 
[0016] Now the Bluetooth protocol stack will be de- 
scribed with reference to Fig. 4. In Fig. 4 two Bluetooth 
units are depicted: a unit Nr. 1, 101, and unit Nr. 2, 102. 
[0017] The BaseBand BB protocol describes the 
specifications of the digital signal processing part of the 
hardware - the Bluetooth link controller, which carries 
the Baseband protocols and other low-level link rou- 
tines. It uses two link types: Synchronous Connection- 
Oriented (SCO) links and Asynchronous Connection- 
Less (ACL) links. The Link Management Protocol LMP 
handles messages used for link set-up, security and 
control. The LMP is located above the Baseband Pro- 
tocol. 

[0018] The Logical Link Control and Adaptation layer 
Protocol L2CAP is also located over the Baseband Pro- 
tocol, L2CAP provides connection-oriented and con- 
nectionless data services to upper layer protocols with 
protocol multiplexing capability, segmentation, reas- 
semble operation, and group abstractions. The L2CAP 
is defined only for ACL links. 

[0019] As previously stated, physical transmission in 
a piconet is allowed exclusively between the master and 
each slave, and vice- versa. Thus, there is no way for a 
slave to send data to another slave in a piconet, since 



direct communication is not allowed. 
[0020] In a Bluetooth system there is no way specified 
to address and route packets from one piconet to an- 
other. However, a BT unit, which is a member of more 
5 than one piconet can be used to forward packets from 
one piconet to another. Such a BT unit is herein called 
a "forwarding node". 

[0021] In order to allow slave-to-slave communication 
in a piconet and inter-piconet communication. One 

10 piece of important information is a slave, which is to 
send a message to another slave in a piconet, e.g. the 
address, such as BD_ADDR of each of the other mem- 
bers of piconet. This information is normally only known 
by the master unit in a piconet. Another example of im- 

15 portant information can be whether a receiving BT unit 
supports slave-to-slave communication. 
[0022] Nokia has proposed to the Bluetooth SIG (Spe- 
cial Interest Group), the organization writing the Blue- 
tooth standard, a new method enabling inter-piconet 

20 routing in a scatternet as well as intra-piconet routing 
between slaves within the same piconet. In the Nokia 
proposal a protocol layer called Virtual Network Seg- 
ment (VNS) is inserted between the L2CAP and the Net- 
work layer 104, see Fig. 4, in order to emulate a shared 

25 medium network, i.e. a broadcast medium, to the Net- 
work layer, i.e. the VNS layer serves the same purpose 
as the NAL layer. The VNS entity in a forwarding node 
will register itself in the master unit by sending a mes- 
sage to its peer entity in the master unit. In the transfer 

30 of messages slave units use the knowledge of the mas- 
ter. When a slave unit wants to send a message to a 
forwarding node, e.g. a request to create a route to a 
specific destination in another piconet, it sends the mes- 
sage to the master unit. The master unit will then forward 

35 the message to the appropriate forwarding node(s) 
based on its retained information. 
[0023] Another example arising from Bluetooth Core 
Specification 1.0, (i.e. Specification of the Bluetooth 
system; Core; Specification Volume 1:1, version 1.0) re- 

*o lates to the compatibility between different BT units. 
When two BT units communicate over a direct wireless 
link, i.e. not slave-to-slave communication via the mas- 
ter unit, the compatibility problem is solved by exchang- 
ing lists of features including indications for each feature 

45 whether it is supported or not. This information ex- 
change is performed using the LMP PDU (Protocol data 
Unit), LMP_features_req and LMP_features_res. A 
message in the Link Manager Protocol (LMP) is called 
"LMP PDU", PDU standing for "Protocol Data Unit". 

50 LMP_features_req and LMP_features_res indicate two 
LMP PDU according to the Bluetooth Core Specification 
1.0. In fact, before this information exchange is per- 
formed a BT unit is allowed to use only a small subset 
of the Bluetooth features, e.g. packet types, when com- 

55 municating with the other BT unit. After the information 
exchange has occurred the intersection of the support- 
ed features in the two BT units may be used. The infor- 
mation being exchanged using LMP_features_req and 



7 



EP1 107 516 B1 



8 



LMP_features_res is a list of Bluetooth features and a 
bit for each feature. The bit indicates whether the feature 
is supported or not, see page 235-236 in the Bluetooth 
Core Specification Volume 1:1. 
[0024] Patent document WO 9914897 discloses a 
system and a method by which wireless nodes of an ad- 
hoc network send their own addresses and addresses 
of their reachable neighbours to a master node. 

SUMMARY OF THE INVENTION 

[0025] The Problems discussed in the present disclo- 
sure are the following: 

• The VNS approach deals with only a small part of 
the general distribution of information. 

• Regarding the LMP procedure for exchange of lists 
of supported features, this is limited to BT units 
communicating over a direct link, i.e. a master unit 
and a slave unit communicating with each other. 
The compatibility issues arising when slave-to- 
slave communication is considered are not ad- 
dressed. 

When slave-to-slave communication within a pi- 
conet is introduced, a problem is that neither the 
AM_ADDR nor the BD_ADDR, or a possible IP ad- 
dress, of other slave units in said piconet are avail- 
able for a slave unit in said piconet. 

[0026] Since Bluetooth is the main target of the inven- 
tion, the method and arrangement as disclosed herein 
is described in a Bluetooth context using Bluetooth ter- 
minology. The term "Bluetooth" is a registered trade- 
mark denomination of a short-range radio transceiver 
and the communication system using such a transceiv- 
er. A man skilled in the art understands that other types 
of short range communication may be used, e.g. infra- 
red light, the devices in such a system being provided 
with means for communication by infrared light. Further 
types of short-range communication may be ultrasonic 
or hydrophonic communication. Furthermore, the inven- 
tion can be applicable, to other network technologies, 
both wired and wireless. 

[0027] Thus a target system is considered which is a 
digital, wired or wireless, communication system consti- 
tuting a network of multiple nodes. The network com- 
prises a central node, also called master and two or 
more peripheral nodes, also called slaves or slave units. 
The central node controls all the communication in the 
network. On the lowest protocol layer, the physical layer, 
all the communication flows exclusively between the 
central node and a peripheral node or vice versa. No 
communication, on the lowest protocol layer, goes di- 
rectly between two peripheral nodes. In such a system, 
information related to the system itself or to the nodes 
in the system can be distributed by the central node 



among the peripheral nodes in the network or kept in a 
database in the central node, which database is acces- 
sible on request from the peripheral nodes in the net- 
work. The information can be conveyed to the central 
5 node from the peripheral nodes, either commanded by 
the central node itself or on request from a peripheral 
node, triggered by an internal event in the peripheral 
node, e.g. a change of state having external conse- 
quences. The distributed information can comprise: 

10 

Number of peripheral nodes 

• Addresses of peripheral nodes 
15 • |p addresses of all nodes 

• Associations between an IP address and a low layer 
address (e.g. Medium Access Control MAC ad- 
dress) for a peripheral node or for all nodes 

20 

• Addresses of forwarding nodes 

Supported features of peripheral nodes 

25 • state changes in peripheral nodes (e.g. when a 
node becomes or ceases to be a forwarding node) 

• Forwarding bit rate capacity of forwarding nodes 

30 • Notifications when nodes join or leave the network 

Notifications when a connection to a fixed infra- 
structure becomes available or ceases to be avail- 
able 

35 

• Notifications of other events 

• Information related to forwarding policy 

40 [0028] Furthermore, it should be noted that the meth- 
ods to be used in a Bluetooth system are not limited to 
the type of information mentioned in conjunction with the 
mechanisms. Any type of information related to the sys- 
tem of the individual nodes could be managed using any 
<5 of the described mechanisms. Such information may be 
the above listed information and can contain: 

• AM_ADDR of slaves 
50 • BD_ADDR of slaves 

• IP address of slaves 

Inter-piconet scheduling parameters for forwarding 
55 nodes 

[0029] Thus, to overcome the above described prob- 
lems and to provide a generally viable solution a piconet 
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the art from this detailed description. 
BRIEF DESCRIPTION OF THE DRAWINGS 
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is a diagram illustrating a standard 
base band packet format, 
is a diagram illustrating the format of 
an ACL packet. 

is a diagram illustrating a base band 
packet header. 

is a diagram illustrating a base band 
payload header for a singe slot pack- 
et. 

is a diagram illustrating a base band 
payload header for a multi slot packet, 
is a schematic view illustrating a Blue- 
tooth transceiver. 

are schematic views of three electron- 
ic devices provided with a Bluetooth 
transceiver. 

is a diagram illustrating the Bluetooth 
protocol layers. 

is a diagram showing the relationship 
between time slots and frequency 
hops in a system using Bluetooth, 
is a diagram illustrating a forwarding 
scenario. 

are diagram illustrating the Baseband 
packet format. 

is a schematic view of two piconets in 
a scatternet. 

is a flowchart illustrating the routing of 
a packet. 

is a diagram illustrating a Bluetooth 
unit. 

is a flowchart illustrating the process 
of a Bluetooth unit becoming a for- 
warding node. 

are flowcharts illustrating an example 
of a process when a Bluetooth unit be- 
comes a forwarding node, 
are flowcharts illustrating an other ex- 
ample of a process when a Bluetooth 
unit becomes a forwarding node, 
is a flowchart illustrating the process 
of a forwarding node ceasing to be a 
forwarding node and the information 
flow in a first piconet. 
are flowcharts illustrating the process 
of a forwarding node ceasing to be a 
forwarding node and the information 
flow in a second piconet. 



55 



must include an efficient mechanism to make all the rel- 
evant information available to all slave units in a timely 
manner. This can be achieved in different ways. Al- 
though different types of information will be described 
in conjunction with different mechanisms, the distribu- 
tion of all the different types of information could be han- 
dled by a common protocol, but separate protocols are 
also feasible. It is also possible to use different protocols 
for the same information in different situations. 
[0030] The purpose of the invention is to provide 
mechanisms for efficient distribution of relevant informa- 
tion in a piconet 

[0031] In a system using Bluetooth technology, an ad- 
vantage of the herein disclosed method and arrange- 
ment is that slave-to-slave communication is facilitated, 
since distribution of useful system or node related infor- 
mation in a piconet is enabled. When slave-to-slave 
communication is enabled it is no longer enough that 
the master unit is informed of relevant information re- 
garding the slave units. Useful information can be e.g.: 

• Address information related to the member units in 
a piconet, including notifications when BT units join 
or leave the piconet. 

• Forwarding node information, which also facilitates 
inter-piconet communication. 

• Compatibility related information. 

[0032] In a system using Bluetooth technology, a fur- 
ther advantage of the herein disclosed method and ar- 
rangement is that slave-to-slave LMP PDU also facili- 
tates slave-to-slave communication. 
[0033] In a mobile telecommunication constituting a 
network of multiple nodes, comprising a central node 
and at least two peripheral nodes, where the central 
node control all the communication in the network, an 
advantage of the herein disclosed method and arrange- 
ment is that communication between peripheral nodes, 
via the central node, is facilitated, since relevant infor- 
mation related to the system and the individual nodes 
can be distributed among the peripheral nodes. The in- 
formation may be any of the above listed. 
[0034] The term "comprises/comprising" when used 
in this specification is taken to specify the presence of 
stated features, integers, steps or components but does 
not preclude the presence or addition of one or more 
other features, integers, steps, components or groups 
thereof. 

[0035] Further scope of applicability of the present in- 
vention will become apparent from the detailed descrip- 
tion given hereinafter. However, it should be understood 
that the detailed description and specific examples, 
while indicating preferred embodiments of the invention, 
are given by way of illustration only, since various 
changes and modifications within the scope of the ap- 
pended claims, will become apparent to those skilled in 



[0037] The invention will now be described in more 
detail with reference to preferred exemplifying embodi- 
ments thereof and also with reference to the accompa- 
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nying drawings. 
DETAILED DESCRIPTION 

[0038] The internal logical structure of a Bluetooth unit 
having an enhanced communication capability appears 
from Fig. 10. The Bluetooth unit 1195 comprises basic 
Bluetooth functions 1 1 50, forwarding functions 1 1 60 and 
a database 1180. The block basic Bluetooth functions 
1150 comprises the functions performed by a transceiv- 
er, a clock, a memory, a power source, logic circuits for 
implementing the Bluetooth protocol stack, logic circuits 
for analyzing signaling messages and logic circuits for 
generating signaling messages, etc. The block forward- 
ing functions 1160 comprises the functions performed 
by forwarding logic circuits, i.e. logic circuits to receive 
a packet in a first piconet, logic circuits to analyze the 
routing and address information located in said packet 
and logic circuits for transmitting a packet to a second 
piconet, etc. The block database 1180 comprises a 
physical memory for storing data, a piconet indicator 
1198, blocks 1197 provided with data related to each 
piconet in which the BT unit is currently a member, a 
block 1179 comprising inter-piconet scheduling param- 
eters, a block 1178 comprising BT unit related data. The 
block 1 198 comprising a piconet indicator includes a da- 
ta unit indicating the piconet, if any, in which the BT unit 
is currently active, i.e. which set of piconet related data 
that is currently valid. The block 1179 "Inter-piconet 
scheduling parameters" include timing parameters gov- 
erning when the BT unit is to be active in each piconet, 
i.e. when to switch from one set of piconet related data 
(in particular the radio related parameters 1173 and the 
timing parameters 1 1 75) to another. The block 1 1 78 "BT 
unit related data" includes data related to the BT unit 
irrespective of the piconet to which the BT unit is located 
e.g. Battery status, user interface options, data entered 
by the user. The blocks 1197 "Data related to the k th pi- 
conet" comprises a block 1196 "master/slave indicator", 
a block 1194 "forwarding node/non-forwarding indica- 
tor", a block 1 1 92 "forwarding related data", a block 1 1 90 
"list of piconet members", i.e. Bluetooth units that are 
connected to the piconet, a block 1170 "list of forwarding 
nodes in the piconet", a block 1173 "radio related pa- 
rameters", and other piconet related data. The block 
1196 "master/slave indicator includes a data unit indi- 
cating whether the BT unit is a master or a slave in the 
piconet. The block 1194 "forwarding node/non-forward- 
ing node indicator" includes a data unit indicating 
whether the BT unit is a forwarding node or not in the 
piconet. The block 1192 "forwarding related 
data" includes data necessar to perform forwarding of 
data from one piconet to another, e.g. list of piconet be- 
ing currently interconnected. The block 1173 "radio re- 
lated parameters" comprises frequency hop sequence 
and currently used transmitter power, The block 
1175 "timing parameters" include an estimate of the 
clock value of the master unit. The block 1 1 70 list of for- 



warding nodes comprises a data record of each forward- 
ing node in the piconet, each data record comprising at 
least 

5 • The AM_ADDR of the forwarding node 

The BD_ADDR of the forwarding node 

[0039] The block 1190 list of piconet members com- 
10 prises 

• A data record of each member unit of the piconet, 
except in some cases the Bluetooth unit itself, each 
record comprising 

15 

• The AM_ADDR of the Bluetooth unit 

• The BD_ADDR of the Bluetooth unit 

20 • Other optional information about the Bluetooth unit, 
e.g. compatibility information 

[0040] In order to allow that information is transferred 
from one slave to another slave in a piconet the infor- 

25 mation on the members of the piconet must be distrib- 
uted to all members of the piconet. Thus, when a source 
slave unit is to transfer information to another slave unit 
the source slave must have access to the address of the 
other slave unit. This address could be the BD_ADDR 

30 or the AM_ADDR or some other address used on a high- 
er layer, e.g. the IP address. The best choice of address 
depends on the addressing scheme used in the piconet. 
A combination of several addresses could sometimes 
also be used to allow translation between addresses, e. 

35 g. between an IP address and a BD_ADDR and/or be- 
tween a BD_ADDR and an AM_ADDR. 
[0041] Thus, e.g. the AM_ADDR and the BD_ADDR 
of all slaves should be made available to all slaves. 
[0042] When transferring information between slaves 

40 in a piconet the routing is performed using the Baseband 
layer protocol, thereby eliminating the need to traverse 
all the protocol layers up to the network layer 105 or a 
NAL layer. The packets containing the information to be 
transferred can be called Baseband Packets and they 

45 are transferred from a first slave, via the master, to a 
second slave. The first slave obtains the address of the 
second slave from the master, inserts it in a header field 
of the Baseband packets and transmits them to the mas- 
ter. The master analyses the address in the header and 

50 forwards the packet to the second slave according to 
the address. Furthermore, when AM_ADDR is used ad- 
dressing, the data overhead represented by a higher 
layer destination address (e.g. an IP address on the IP 
layer or a BD_ADDR on the NAL layer) is completely 

55 eliminated. 

[0043] To make the presence of a new member, and 
the relevant address(es) of this new member, known to 
the other slave units in the piconet as soon as possible, 



13 



EP1 107 516 B1 



14 



it is preferable that the master unit distributes the ad- 
dress information of the new slave unit as soon as the 
new slave unit has been connected to the master. The 
master unit should also inform the new slave unit of the 
slave units being already present in the piconet, by 
transferring the relevant information and in particular the 
address information for all the already existing slave 
units. Similarly, the master unit informs all the other 
slave units in the piconet, when a slave unit leaves the 
piconet. When a slave unit leaves the piconet it is de- 
tected explicitly or implicitly by time-out due to loss of 
radio contact. An alternative distributing mechanism is 
that the master periodically distributes the address in- 
formation of all the slave units in the piconet. Of course, 
it is also possible to combine "event triggered" the time 
driven distribution of information. 
[0044] The distribution mechanism could be either 
broadcasting to all the piconet members at once, al- 
though the Bluetooth intra-piconet broadcast mecha- 
nism is not reliable, since the messages are not ac- 
knowledged, or unicast from the master unit to each 
slave unit, one at a time. If the address information of 
all the slave units is periodically unicast to each slave 
unit, the address information of the slave unit receiving 
the information should of course be excluded from the 
message. The protocol to be used could be LMP (in- 
cluding new PDUs) or a VNS layer protocol. There are 
also other proposals of adaptation layers between 
L2CAP and the Network layer, e.g. called Network Ad- 
aptation Layer (NAL), which could also include this pro- 
tocol. Other protocols may also be used for this purpose. 
[0045] A BT unit can only transmit and receive data 
in one piconet at a time, so participation in multiple pi- 
conets has to be on a time division multiplex basis. The 
time spent in each piconet is governed by a scheduling 
algorithm. This algorithm could be designed in various 
ways according to different principles, e.g. fixed round 
robin, negotiation between a slave unit and a master unit 
(when applicable), dynamically assigned time windows 
(by the master of a piconet based on the current traffic, 
etc. When a BT unit switches from one piconet to an- 
other, it has to start using another set of piconet related 
data, as shown in fig. 10. In particular, the radio related 
parameters, e.g. the frequency hop sequence, and the 
timing parameters, e.g. the clock value of the master of 
the piconet, have to be switched in order for the Blue- 
tooth unit to be able to communicate in the new piconet. 
In fig. 10 different sets of piconet related data in a BT 
unit are illustrated, as well as a piconet indicator indicat- 
ing which of the sets of piconet related data that is cur- 
rently valid. 

[0046] To allow inter-piconet communication, the ad- 
dress of each forwarding node that is present in the pi- 
conet must also be distributed. This address could be 
AM_ADDR, the BD_ADDR, an IP address or even a 
VNS or NAL specific address, or similar address. In the 
same way as for general address information of a slave 
member, also in this case, any combination of these ad- 



dresses could be useful depending on the addressing 
and routing mechanisms used in the piconet and the 
scatternet, and the independent use of the address in- 
formation. Distribution of forwarding node information 

5 could be handled separately or in conjunction with the 
distribution of the general address information of all the 
slave units in the piconet. If provided in conjunction with 
the distribution of address information, there could be 
an indicator for each slave unit indicating whether it is a 

10 forwarding node or not. When forwarding node informa- 
tion is considered, this concerns the master too, since 
the master may also be a forwarding node. If the for- 
warding node information is distributed along with the 
slave unit address information, and the master unit hap- 

15 pens to be a forwarding node, this status of the master 
unit has to be added to the information of the slave units. 
[0047] Even if the forwarding node information is in- 
cluded in the distribution of slave unit address informa- 
tion, it must still be possible to distribute forwarding node 

20 information separately if event triggered distribution is 
used. When a BT unit becomes a forwarding node, the 
other members of the piconet must be informed. Like- 
wise, when a BT unit ceases to be a forwarding node, 
the other piconet members should be informed. This in- 

25 formation could be broadcast or unicast by the master 
unit to the other slave units, but first the concerned BT 
unit, i.e. the unit that become or cease to be a forwarding 
node, must inform the master unit. This is preferably 
done via messages on the VNS layer or NAL layer, or a 

30 similar layer, but the messages could also be carried by 
new LMP PDUs or by another protocol. 
[0048] In a further embodiment, the BT unit that has 
changed its forwarding status, from not being a forward- 
ing node to being one or vice versa, notifies the other 

35 piconet members directly via slave-to-slave communi- 
cation. 

[0049] In order to attend to the compatibility problem 
in slave-to-slave communication within a piconet, the 
master unit could simply distribute the list of supported, 

40 and unsupported, features for a certain slave unit to- 
gether with the address information for the concerned 
slave unit. The list of features should first be obtained 
from the new slave unit by the master unit via the 
LMP_features_req LMP_features_res procedure, al- 

45 though the list of features must be extended to cover e. 
g. support for the shared medium emulation layer, e.g. 
the NAL layer, if used, forwarding capability, support for 
slave-to-slave intra-piconet communication, etc. 
Changes in the list of supported features in already ex- 

50 isting piconet members should also be communicated 
to the other piconet members. This could be done by 
first informing the master unit, unless the concerned unit 
itself is the master unit, which then distributes it to the 
other slave units using broadcast or multiple unicast 

55 messages. An alternative is that the concerned slave 
unit distributes the new list of supported, and unsupport- 
ed, features, or possibly just the modifications of the old 
list, to the other slaves using slave-to-slave communi- 
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cation and to the master unit using slave-to-master uni- 
cast. 

[0050] In a yet further method for providing useful in- 
formation, i.e. any of the above mentioned types of in- 
formation and possibly other useful information, to all 
the member units of a piconet is to store all the informa- 
tion in the master unit, e.g. a database, and making said 
information accessible on request from the slave units. 
A slave unit would then be able to request all the infor- 
mation in the database of the master or a relevant sub- 
set of said information from the master. A relevant sub- 
set would e.g. be all address information, all forwarding 
node information, or address information for a selected 
unit. 

[0051] The request and response could be carried by 
LMP or a specifically designated protocol or by different 
protocols, depending on the type of information that is 
requested. 

[0052] Before a slave unit can request any information 
from the master unit, the relevant information must be 
conveyed from the slave units to the master unit. This 
could be done on request from the master unit or trans- 
mitted from a slave unit triggered by an internal event in 
the slave unit, e.g. a switch from being a forwarding 
node to not being one. Such a "master unit database" 
method may be used as a stand-alone solution or as a 
back up mechanism for any of the distribution mecha- 
nisms described above. 

[0053] In another embodiment, a method for attend- 
ing to compatibility problems during slave-to-slave com- 
munication is to allow the LMP_features_req and 
LMP_features_res PDU to go slave-to-slave, i.e. essen- 
tially traversing two hops within a piconet. This method 
requires that both the involved slave units support slave- 
to-slave communication, but also other information of 
the support of other features, e.g. support of a the mod- 
ified Baseband packet header format described in the 
simultaneously filed patent application (Method, node 
and arrangement in a communication network) and dis- 
cussed in more detail in conjunction with Fig. 1a-e. 
[0054] In Fig. 6 a Bluetooth network or scatternet 601 
is illustrated comprising two piconets. The first piconet 
602 comprises multiple nodes A, B, C, D, E and F, the 
node F being the master and the other nodes A, B, C, 
D, E being slaves. The second piconet 603 comprises 
multiple nodes E, G, H, I and J, the node J being the 
master, and the other nodes E, G, H and I being slaves. 
The respective slaves A, B, C, D and E communicate 
with the master F over radio links 604. The respective 
slaves E, G, H and I are communicating with the master 
J over radio links 605. The unit E is a slave in both the 
first piconet 602 and in the second piconet 603 and acts 
as a forwarding node, when transferring packets be- 
tween the first piconet 602 and the second piconet 603. 
The Bluetooth network 601 thus comprises two masters 
F and J and one forwarding node E. Within the network, 
a Baseband packet is transferred, the Baseband packet 
having a header, as shown in Figs. 1a and 1b. The mas- 



ter F controls all the communication within the first pi- 
conet 602 and the master J controls all the communica- 
tion within the second piconet 603. A packet, also called 
a Baseband packet as in slave-to-slave communication, 

5 may be routed from a first node A in the first piconet via 
the master F, the forwarding node E and the master J, 
to a second node G in the second piconet. To perform 
the transmission of the packet, a route is created be- 
tween the first node A and the second node G, each 

10 packet being sent along the route comprising routing in- 
formation, originating from the Network layer or NAL lay- 
er. When a routing protocol called AODV (Ad-Hoc On 
demand Distance Vector) is used, the routing informa- 
tion is the address of the destination node, in this case 

15 that of the second node G. When a routing protocol 
called Dynamic Source Routing is used, the routing in- 
formation comprises the address of each node to be tra- 
versed along the route and the destination address, 
which in this case comprise the addresses of the nodes 

20 F, E, J and G. In order to perform the packet transmis- 
sion using the Baseband protocol in the physical layer, 
the routing information is placed in a header of a lower 
protocol, i.e. in the payload header field implying a short- 
circuiting of both the Baseband payload sublayer and 

25 the L2CAP layer. The term short-circuiting a protocol 
layer as used herein means that the forwarding node 
and the master node does not have to unpack and an- 
alyze the information of said protocol layer, in order to 
forward the packet. 

30 [0055] In Fig. 7c a diagram of the Baseband packet 
header format is shown. In Fig. 7a the payload header 
format of a Baseband packet for single slot packets is 
shown. In Fig. 7b a diagram of the format for Baseband 
packets of multi-slot type is shown. The headers shown 

35 jn Fig. 7a-c are, relatively the headers depicted in Fig. 
1c-e, enlarged by a forwarding indicator field FORW IND 
and a relevant routing indicator field ROUTING INFO. 
The forwarding indicator instructs a forwarding node 
that it should send the packets to the upper layer proto- 

40 cols, when the forwarding indicator is not set, e.g. 
FORW IND=0, or that it should invoke a forwarding proc- 
ess within the lower layer, when the forwarding indicator 
is set, e.g. FORW IND=1 . The setting of the forwarding 
indicator also indicates that it is followed by the address 

45 information that is required to forward the packet. If the 
forwarding indicator is not set, no routing information is 
included. Alternatively, the routing information may be 
included, indicating to the receiving node that said re- 
ceiving node is the destination node and thus that the 

so packet is to be sent to upper layer protocols. This low 
level routing method may be used for data packets being 
sent along an already established route. The message 
that was used to create the route in the first place, e.g. 
NAL or a Network layer message, cannot use the pro- 

55 cedure as described herein. 

[0056] Now, packet transmission the network layer, 
the packet may be much larger than in the physical layer. 
The NAL or Network layer packets will probably fit into 



17 



EP1 107 516 B1 



18 



a single L2CAP packet, but the L2CAP packets may of- 
ten have to be segmented before they are transferred 
in multiple Baseband packets. The fact that the routing 
information is included in every Baseband packet, in- 
stead of only in the NAL or Network layer packet, in- 
creases the overhead. In one embodiment, a L2CAP 
packet is segmented into multiple Baseband packets to 
be transmitted, wherein a first Baseband packet com- 
prises the first segment of the L2CAP packet, and the 
subsequent Baseband packets comprise the respective 
subsequent segments of the L2CAP packet. In a further 
embodiment, the forwarding indicator is set, and routing 
information is inserted in the first and the subsequent 
Baseband packets. 

[0057] In a yet further embodiment, the forwarding in- 
dicator is set and the routing information is inserted only 
in the first Baseband packet, but in the subsequent 
Baseband packets no routing information is included. In 
this case, the forwarding indicator within the first Base- 
band packet also instructs the forwarding node E and 
the masters F and J (as shown in Fig. 6) to store the 
routing information of the first Baseband packet and as- 
sociate the routing information with the incoming link, i. 
e. the link on which the first Baseband packet is received 
by the forwarding node E and on which also the subse- 
quent Baseband packets will be received by the for- 
warding node E. The forwarding indicator has to be com- 
plemented with yet a one-bit indicator, which is called 
Routing Information Indicator (Rll). The Rll is set only 
when the forwarding indicator is set. The purpose of the 
Rll is to indicate whether the routing information is ac- 
tually included after the forwarding indicator. For the first 
Baseband packet the Rll packet is set e.g. = 1 , indicating 
thatthe routing information is present. In the subsequent 
respectively Baseband packets the forwarding bit is set, 
the Rll is cleared, e.g. = 0, indicating that no routing in- 
formation is present. Then, the forwarding node E, and 
the master nodes F and J , use the latest received routing 
information to forward the subsequently received Base- 
band packets, until new routing information is received 
in a Baseband packet. 

[0058] In Fig. 9 is a flowchart illustrating how a packet 
is routed from a first node A in a first piconet via a for- 
warding node E to a second node G in a second different 
piconet in the physical layer using the Bluetooth protocol 
of a Bluetooth network comprising multiple nodes. In 
block 901 , the first node A indicates in a header of a 
Baseband packet that the packet should be forwarded. 
Thereafter, in block 902, the first node A inserts relevant 
information in the header of the Baseband packet. Then, 
in block 903, the first node transmits the packet using 
slave-to-slave communication to the forwarding node E. 
Thereafter, in block 904, the forwarding node E analyses 
the forwarding indication and the routing information of 
the received Baseband packet. Then, in block 905, the 
forwarding node E short-circuits the Logical Link Control 
and Adaptation Layer Protocol (L2CAP) layer of the 
packet. Finally, in block 906, the forwarding node E for- 



wards the packet to the destination node, i.e. the second 
node G, according to the received routing information, 
using slave-to-slave communication. 
[0059] Now a process illustrating how a node be- 

5 comes a forwarding node will be described. First, the 
information flow in the first piconet will be described with 
reference to the flowchart in Fig. 11 . Two cases must be 
considered; the considered Bluetooth unit may be a 
slave unit or a master unit of the first piconet. In block 

10 1510 a Bluetooth unit A is a member of a first piconet. 
Then, in block 1520, said unit A joins a second piconet 
using the INQUIRY and PAGE procedures, specified in 
the Bluetooth standard. In block 1530 it is checked 
whether the unit A is the master of the first piconet. If 

15 the unit A is the master of the first piconet, the flow pro- 
ceeds directly to block 1550. If the unit A is not the mas- 
ter of the first piconet, the flow goes to block 1540. In 
block 1540 the unit A informs the master of the first pi- 
conet of its new forwarding node status, optionally in- 

20 eluding other information, such as the BD_ADDR of the 
master of the second piconet, the master clock value 
and scheduling parameters of the second piconet. 
Then, in block 1550 the master unit of the first piconet 
enters data concerning unit A in its list of forwarding 

25 nodes in the piconet, including e.g. the AM_ADDR and 
BD_ADDR of unit A and other optional information. 
Thereafter, in block 1560, the master unit of the first pi- 
conet transmits information about the new forwarding 
node, all the information being stored in the master unit, 

30 or a subset thereof, to the at least one of the slave units, 
except unit A, when unit A is a slave unit in the first pi- 
conet and unless the intra-piconet broadcast mecha- 
nism is used to convey the information. Finally, the flow 
goes to block 1570. In block 1570 each receiving slave 

35 unit inserts the received forwarding node information in 
its list of forwarding nodes in the piconet, of which the 
receiving slave unit is a member. 
[0060] Now the information flow in the second piconet 
when a node becomes a forwarding node will be dis- 

40 closed. There are two cases having two alternative ways 
to distribute information in the piconet, resulting in four 
different cases: 

The new unit is a slave in the second piconet 

45 

Case 1 : First the piconet member information 
is distributed, thereafter, the forwarding node 
information is distributed. 
Case 2: Piconet member information and for- 
50 warding node information are distributed to- 

gether. 

The new unit is the master of the second piconet, i. 
e. the second piconet was just created. 

55 

Case 3: First, the piconet member information 
is distributed, thereafter, the forwarding node 
information is distributed. 
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Case 4: Piconet member information and for- 
warding node information are distributed to- 
gether 

[0061] The cases 1 and 3 will now be disclosed with 
reference to the flowchart in Fig. 12a and Fig. 12b. In 
block 2100 of Fig. 12a, a Bluetooth unit A is a member 
of a first piconet. Then, in block 2110 the unit A joins a 
second piconet using the INQUIRY and PAGE proce- 
dures specified in the Bluetooth standard. In block 2115 
it is determined whether the unit A is a master of the 
second piconet. If the unit A is the master of the second 
piconet, the BD_ADDR of unit A is already known to the 
at least one slave unit of the second piconet. Since unit 
A is the master unit, it has no AM_ADDR. Thus, when 
unit A is the master of the second piconet, the flow pro- 
ceeds to block 21 20, in which other relevant information, 
e.g. compatibility information such as a list of supported 
and unsupported features, IP address, etc. is transmit- 
ted to the at least one slave unit of the second piconet. 
Thereafter, the flow goes to Fig 12b, which will be dis- 
cussed below. When the unit A is a slave unit of the sec- 
ond piconet, the flow goes from block 2115 to 2125. 
When the unit A is a slave unit of the second piconet, 
the BD_ADDR and the AM_ADDR of unit A is already 
known to the master of the second piconet. In block 
2125, other relevant information, e.g. compatibility infor- 
mation such as a list of supported and unsupported fea- 
tures, IP address, etc. is transmitted from unit A to the 
master unit of the second piconet. Thereafter, the flow 
goes to block 2130. In block 2130 the master unit of the 
second piconet stores the received information in its da- 
tabase, preferably in its list of piconet members. Then, 
in block 2135 the master unit of the second piconet 
sends BD_ADDR and AM_ADDR of each of the other 
slave units in the second piconet, information which it 
has previously received from each of the other slave 
units in the second piconet, entirely or a subset thereof, 
and the corresponding information on the master unit of 
the second piconet, excluding BD_ADDR, which is al- 
ready known to unit A, and the AM_ADDR, which does 
not exist, to unit A. Together with the above information, 
or as a separate transmission, the master of the second 
piconet also sends information about the forwarding 
nodes in the second piconet to unit A. Then, in block 
2140 unit A inserts a new record having relevant data 
for each of the other slave units in the second piconet 
in its database, preferably in its list of piconet members. 
The received information about the master unit of the 
second piconet is also stored in the list of piconet mem- 
bers, or elsewhere in the database. Thereafter the flow 
go to block 2145 in which unit A inserts a new record 
having relevant data for each of the other forwarding 
nodes in the second piconet in its database, preferably 
in the list of forwarding nodes in the piconet, including 
in each record, e.g. BD_ADDR, and the AM_ADDR, 
when present, of the forwarding node and other optional 
information. Then, in block 2150 the master unit of the 



second piconet sends the BD_ADDR and the 
AM_ADDR of unit A and the information which it re- 
ceived from unit A, entirely or a subset thereof, to the 
other at least one slave unit in the second piconet, i.e. 

5 excluding unit A, unless the intra-piconet broadcast 
mechanism is used to convey the information. Thereaf- 
ter the flow goes to block 2155 in which each receiving 
slave unit inserts a new record having relevant data con- 
cerning unit A in its database, preferably in its list of pi- 

10 conet members. Then, in block 2160 the unit A delivers 
information about its forwarding node status to the mas- 
ter unit of the second piconet. Thereafter, in block 2165 
the master unit of the second piconet inserts a record 
concerning unit A in its list of forwarding nodes in the 

*5 piconet, comprising e.g. the AM_ADDR and the 
BD_ADDR of unit A and other optional information. 
Then, in block 2170 the master unit of the first piconet 
transmits information concerning the new forwarding 
node, all the information stored in the master unit or a 

20 subset thereof, to the at least one slave unit, except unit 
A, when unit A is a slave unit of the first piconet, and 
unless the intra-piconet broadcast mechanism is used 
to convey information. Finally, in block 2175 each re- 
ceiving slave unit inserts the received forwarding node 

25 information in its list of forwarding nodes in the piconet. 
[0062] Fig. 12b discloses the continued information 
flow, after block 2120. The BD_ADDR and the 
AM_ADDR of each of the slave units in the second pi- 
conet is already known to unit A, since unit A is the mas- 

30 ter unit of the second piconet, and in a block 2180 unit 
A collects other information relevant to the slaves, if any, 
e.g. compatibility information, such as a list of supported 
and unsupported features. When a slave unit is a for- 
warding node, the forwarding node status and optional 

35 related information is also transferred to and collected 
by unit A. Then, in block 21 82 unit A inserts the received 
information in the already existing records in its list of 
piconet members. Thereafter, in block 2184 unit A in- 
serts information of each slave unit which is a forwarding 

to node, in its list of forwarding nodes in the piconet, the 
information comprising e.g. AM_ADDR and the 
BD_ADDR and other optional information. The 
BD_ADDR of unit A is already known to the slave units 
of the second piconet and since unit A is the master unit, 

45 jt has no AM_ADDR, but in the next block, other relevant 
information is transmitted to the at least one slave units 
of the second piconet, e.g. compatibility information, 
such as a list of supported and unsupported features, 
IP addresses, etc. Then in block 2190, each receiving 

so slave unit stores the relevant data concerning unit A in 
its database, e.g. in its list of piconet members. Then, 
in block 2192, unit A sends information concerning its 
forwarding node status to the at least one slave units of 
the second piconet. Finally, in block 2194, each receiv- 

55 jng slave unit inserts the received forwarding node in- 
formation in its list of forwarding nodes in the piconet, 
including e.g. the BD_ADDR and other optional infor- 
mation. 
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[0063] The cases 2 and 4 will now be discussed with 
reference to the flowchart in Fig. 13a and Fig. 13b. In 
block 5500, Fig. 13a, a Bluetooth unit A is a member of 
a first piconet. Then, in block 5510 said unit A joins a 
second piconet using the INQUIRY and PAGE proce- 
dures being specified in the Bluetooth specification. In 
block 5520 it is determined whether the unit A is a mas- 
ter of the second piconet. If the unit A is the master of 
the second piconet, the flow goes to Fig 13b, which will 
be discussed below. In the case where the unit A is a 
slave unit of the second piconet, the flow goes from 
block 5520 to 5530. When the unit A is a slave unit of 
the second piconet, the BD_ADDR and the AM_ADDR 
of unit A are already known to the master of the second 
piconet. In block 5530 other relevant information, e.g. 
compatibility information such as a list of supported and 
unsupported features, IP address, etc., is transmitted to- 
gether with information concerning the forwarding node 
status of unit A, from unit A to the master unit of the 
second piconet. Thereafter, the flow goes to block 5535. 
In block 5535, the master unit of the second piconet 
stores the received information in its database. Prefer- 
ably, part of the information, e.g. excluding the informa- 
tion concerning the forwarding status of unit A, is stored 
in the list of piconet members and the information con- 
cerning the forwarding node status of unit A, together 
with e.g. BD_ADDR and AM_ADDR of unit A is entered 
in the list of forwarding nodes. Then, in block 5540 the 
master unit of the second piconet sends BD_ADDR and 
AM_ADDR of each of the other slave units in the second 
piconet, the information which it has previously received 
from each of the other slave units in the second piconet, 
entirely or a subset thereof, and the corresponding in- 
formation about the master unit of the second piconet, 
excluding BD_ADDR, which is already known to unit A, 
and the AM_ADDR, which does not exist, to unit A. To- 
gether with the above mentioned information, or as a 
separate transmission, the masterof the second piconet 
also sends information about the forwarding nodes in 
the second piconet to unit A. Then, in block 5545 unit A 
inserts a new record having relevant data for each of the 
other slave units in the second piconet in its database, 
preferably in its list of piconet members. The received 
information about the master unit of the second piconet 
is also stored in the list of piconet members, or else- 
where in the database. Thereafter, the flow goes to block 
5550, wherein unit A inserts a new record with relevant 
data for each of the other forwarding nodes in the sec- 
ond piconet in its database, preferably in the list of for- 
warding nodes in the piconet, including in each record, 
e.g. BD_ADDR, and the AM_ADDR, when present, of 
the forwarding node and other optional information. 
Then, in block 5555, the master unit of the second pi- 
conet sends the BD_ADDR and the AM_ADDR of unit 
A and the information which it received from unit A, en- 
tirely or a subset thereof, to the other at least one slave 
unit in the second piconet, i.e. excluding unit A unless 
the intra-piconet broadcast mechanism is used to con- 



vey the information. Finally, the flow go to block 5560, 
wherein each receiving slave unit stores ail or parts of 
the received data in its database. Preferably part of the 
data, e.g. excluding the data concerning the forwarding 
5 node status of unit A, is inserted in the list of piconet 
members. The data concerning the forwarding node sta- 
tus of unit A, together with e.g. the BD_ADDR and 
AM_ADDR of unit A is inserted in the list of forwarding 
nodes. 

10 [0064] Fig. 13b discloses the information flow, in the 
case where unit A is a master, after block 5520 in Fig 
13a. The BD_ADDR and the AM_ADDR of each of the 
slave units in the second piconet are already known to 
unit A, since unit A is the master unit of the second pi- 

15 conet. Thus, in block 5560, unit A collects other relevant 
information, if any, e.g. compatibility information, such 
as a list of supported and unsupported features. When 
a slave unit is a forwarding node, the forwarding node 
status and optional related information is also trans- 

20 ferred to unit A. Then in block 5562, unit A inserts the 
received information in the already existing records in 
its list of piconet members. Thereafter, in block 5564, 
unit A inserts information of the possibly at least one 
slave units being forwarding nodes in its list of forward- 

25 ing nodes in the piconet, comprising e.g. AM_ADDR and 
the BD_ADDR and other optional information. The 
BD_ADDR of unit A is already known to the slave units 
of the second piconet and since unit A is the master unit, 
it has no AM_ADDR. Thus, in block 5560 other relevant 

30 information is transmitted to the at least one slave unit 
of the second piconet, e.g. compatibility information, 
such as list of supported and unsupported features, IP 
address, etc. Then in block 5570, each receiving slave 
unit stores the relevant data concerning unit A in its da- 

35 tabase, e.g. in its list of piconet members. Then, in block 
5572, each receiving slave unit inserts the received for- 
warding node information in its list of forwarding nodes 
in the piconet, including e.g. the BD_ADDR and other 
optional information. 

40 [0065] The scenario when a Bluetooth unit ceases to 
be a forwarding node will now be considered. A Blue- 
tooth unit A is assumed to be a member of a first and a 
second piconet and thus constitutes a forwarding node 
in both piconets. Unit A then leaves the second piconet. 

^5 Fig. 14 is a flowchart illustrating the information flow in 
the first piconet when a unit A ceases to be a forwarding 
node. There are two cases to consider: 

Unit A is a slave unit in the first piconet 
so • Unit A is the master of the first piconet 

[0066] In Fig 14, as stated in block 4100, unit A is a 
member of a first and a second piconet. Then, the flow 
goes to block 4110, wherein the unit A leaves the second 
55 piconet, in accordance with known procedures specified 
in the Bluetooth standard, either explicitly, by sending 
or receiving the LMP PDU LMP_detach, or implicitly by 
connection time-out due to loss of radio contact. Then 
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in block 41 20, it is decided whether the unit A is the mas- 
ter of the first piconet. If unit A is the master the flow 
goes to block 4 1 30. If the unit A is a slave unit in the first 
piconet, the unit A sends a message to the master unit 
of the first piconet, indicating that unit A is no longer a 5 
forwarding node. If unit A is present in its own list of for- 
warding nodes, then the record comprising unit A is re- 
moved from this list. Then, in block 41 30, the master unit 
of the first piconet removes the record comprising unit 
A from its list of forwarding nodes. Thereafter, in block 10 
4135, the master unit of the first piconet informs the at 
least one slave units of the first piconet, excluding A 
when unit A is a slave unit of the first piconet and unless 
the intra-piconet broadcast mechanism is used to con- 
vey the information, that unit A has ceased to be a for- 15 
warding node. Finally, in block 4140, each receiving 
slave unit removes the record comprising unit A from its 
list of forwarding nodes. 

[0067] Now the information flow when a Bluetooth unit 
ceases to be a forwarding node in the second piconet 20 
will be disclosed with reference to Figs. 15a and 15b. 
There are two cases to be considered: 

• Case 1 : First, the indication that unit A has ceased 
to be a forwarding node is distributed, thereafter the 25 
indication that unit A has left piconet is distributed. 
Case 2: Only the indication that unit A has ceased 
to be a forwarding node is distributed. The fact that 
unit A can no longer be a forwarding node in the 
piconet is assumed implicitly. 30 

[0068] The trivial cases, where unit A is the master of 
the second piconet, in which case the second piconet 
breaks down when the master unit leaves, and where 
the second piconet comprises only one unit apart from 35 
unit A, in which case there are no other units to which 
information is to be distributed are not described in de- 
tail. 

[0069] Now, the first case will be described with refer- 
ence to Fig. 1 5a. First, as stated in block 71 00, a unit A *o 
is assumed to be a member of a first and a second pi- 
conet, the unit A being a slave unit in the second piconet. 
Then, in block 7110, the unit A leaves the second pi- 
conet, in accordance with procedures specified in the 
Bluetooth standard, either explicitly, by sending or re- 45 
ceiving the LMP PDU LMP_detach, or implicitly by con- 
nection time-out due to loss of radio contact. Thereafter, 
in block 7115, the master unit of the second piconet de- 
tects that the unit A has left the second piconet, using 
known mechanism specified in the Bluetooth standard, so 
Then, in block 7120, the master unit of the second pi- 
conet removes the record comprising unit A from its list 
of forwarding nodes, in block 7125, the master unit of 
the second piconet informs the at least one slave unit of 
the second piconet that unit A has ceased to be a for- 55 
warding node. Then, in block 7130, each slave unit re- 
moves the record comprising unit A from its list of for- 
warding nodes. In block 7 1 40, the master unit of the sec- 



ond piconet removes the record comprising unit A from 
its list of piconet members. Thereafter, in block 7145, 
the master unit of the second piconet informs the at least 
one slave unit of the second piconet that unit A has left 
the piconet. Finally, in block 7150, each receiving slave 
unit removes the record comprising the unit A from its 
list of piconet members. 

[0070] Now, the second case will be disclosed with 
reference to Fig. 15b. First, in block 7200, a unit A is a 
member of a first and a second piconet, the unit A being 
a slave unit in the second piconet. Then, in block 7210, 
the unit A leaves the second piconet, in accordance with 
procedures specified in the Bluetooth standard, either 
explicitly, by sending or receiving the LMP PDU 
LMP_detach, or implicitly by connection time-out due to 
loss of radio contact. Thereafter, in block 7220, the mas- 
ter unit of the second piconet detects that the unit A has 
left the second piconet, using known mechanism spec- 
ified in the Bluetooth standard. Then, in block 7230, the 
master unit of the second piconet checks whether unit 
A was included in the list of forwarding nodes and re- 
moves the record comprising unit A from its list of for- 
warding nodes. In block 7240, the master unit of the sec- 
ond piconet removes the record comprising unit A from 
its list of piconet members. In block 7250, the master 
unit of the second piconet informs the at least one slave 
units of the second piconet that unit A has left the pi- 
conet. In block 7260, each receiving slave unit checks 
whether unit A was included in the list of forwarding 
nodes and then removes the record comprising unit A 
from its list of forwarding nodes. Finally, in block 7270, 
each receiving slave unit removes the record compris- 
ing unit A from its list of piconet members. 
[0071] The invention being thus described, it will be 
obvious that the same may be varied in many ways. 
Such variations and all such modifications as would be 
obvious to one skilled in the art are intended to be in- 
cluded within the scope of the following claims. 



Claims 

1. A digital communication (601) system comprising 
nodes (A, B, C, D, E, F), the nodes including a cen- 
tral (F) node and at least two peripheral nodes (A, 
B), the central node comprising all means for the 
communication in the system and a memory (1180) 
for storing information related to the system itself 
and/or the individual nodes, the nodes each com- 
prising a transmitter and a receiver (1150), and in- 
formation only being directly transferred between 
the central node and each of the peripheral nodes, 
characterized by control means in the central node 
(1150) for transferring information stored in the 
memory means related to the system and/or the in- 
dividual nodes to every peripheral node. 

2. A digital communication system according to claim 
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10. A method according to claim 9 t characterized in 
that part of said information transferred to every pe- 
ripheral node is derived from information conveyed 
from the peripheral nodes to the central node when 

5 requested by the central node. 

11. A method according to claim 9, characterized in 
that part of said information transferred to every pe- 
ripheral node is derived from information conveyed 

10 from the peripheral nodes to the central node initi- 
ated by the peripheral nodes in particular triggered 
by an event in the respective peripheral node. 

12. A method according to claim 9, characterized in 
is that said information is, entirely or in part, address 

information comprising an address of each of the 
peripheral nodes. 

13. A method according to claim 9, characterized in 
20 that said information is, entirely or in part, compat- 
ibility related information. 

14. A method according to claim 9, characterized in 
that all direct transfer of information is made wire- 

25 lessly, in particular using short range radio waves. 

15. A method according to claim 9, characterized in 
that the digital communication system is a Blue- 
tooth piconet. 

30 

16. A method according to any of claim 9-15, charac- 
terized in that the transferring of said information 
is performed using a Bluetooth broadcast mecha- 
nism. 

35 

17. A method according to any of claim 9-15, charac- 
terized in that the transferring of said information 
is performed using the Bluetooth unicast system to 
each peripheral node in turn. 

40 

18. A method according to any of claim 9-17, charac- 
terized in that the transferring of said information 
is made using the Bluetooth LMP protocol. 



25 

1 , characterized in that each peripheral node com- 
prises means for storing said information. 

3. A digital communication system according to claim 
1, characterized in that the direct transferring of 
information is made wireless, in particular using 
short range radio waves. 

4. A digital communication system according to claim 
1, characterized in that the control means in the 
central node are arranged to transfer address infor- 
mation comprising at least one address of each of 
the peripheral nodes. 

5. A digital communication system according to claim 
1, characterized in that the control means in the 
central node are arranged to transfer compatibility 
related information. 

6. A digital communication system according to claim 
1, characterized in that the system is a Bluetooth 
piconet. 

7. A digital communication system according to claim 
1 , characterized in that a first one of the nodes is 
a central node of a first group of the nodes and a 
second one of the nodes is a central node of a sec- 
ond group of the nodes, the first and second nodes 
being different nodes and the nodes being capable 
of being members in both the first and second 
group, each node having first memory means for 
storing information relating to information on the 
first one of the nodes and on the nodes of the first 
group and second memory means for storing infor- 
mation relating to information on the second one of 
the nodes and on the nodes of the second group. 

8. A digital communication system according to claim 
7, characterized in that the nodes have control 
units connected to the transmitters and receivers for 
transferring to a central node information on a 
change of a node to being or to finishing being a 
member in both the first and second groups. 

9. A method in a digital communication system (601) 
comprising nodes (A, B, C, D, E, F), the nodes in- 
cluding a central node (F) and at least two periph- 
eral nodes (A, B), information only being directly 
transferred between the central node and each of 
the peripheral nodes, the central node controlling 
all the communication in the system, and informa- 
tion related to the system itself and/or the individual 
nodes being stored in the central node (1180), char- 
acterized in that information stored in the central 
node and related to the system and/or the nodes is 
transferred from the central node to every peripher- 
al node. 



45 19. A method according to any of claim 9-17, charac- 
terized in that the transferring of said information 
is made using a protocol layer between the L2CAP 
and the network layer, said protocol layer emulating 
a shared medium network towards the network lay- 
so er. 

20. A method according to any of claim 13-19, charac- 
terized in that the transferring of said information 
is made when a new peripheral node joins the digital 

55 communication system. 

21. A method according to any of claim 13-20, charac- 
terized in that, when a new peripheral node joins 
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the system, the part of said information related to 
alt the other peripheral nodes is transferred from the 
central node to said new peripheral node. 

22. A method according to any of claim 9-20, charac- 
terized in that a message is transferred from the 
central node to all the peripheral nodes when one 
of the peripheral nodes has left the system. 

23. A method according to claim 9, wherein a first one 
of the nodes is a master node of a first group of the 
nodes, a second one of the nodes is a master node 
of a second group of the nodes, the first and second 
ones of the nodes being different nodes and the 
group of first nodes and the group of second nodes 
together with the second one of the nodes having a 
node in common, this node being a forwarding 
node, characterized in that when a node changes 
from being a forwarding node to not being a for- 
warding node, or vice versa, a message is sent to 
all the nodes in the first and second groups except 
the node itself. 

24. A method according to claim 23, characterized in 
that the message is sent from the master nodes of 
the first and second groups. 

25. A method according to claim 23, characterized in 
that the message is sent from the node itself. 

26. A method according to claim 23, characterized in 
that before sending the message, information of the 
change of forwarding node status in the node is 
transferred from the node to the master node of the 
first group, and to the master node of the second 
group, provided that the node is not the master node 
of the second group. 



Patentanspruche 

1 . Digitalkommunikationssystem (601 ), die Knoten (A, 

B, C, D, E, F) umfassend, wobei die Knoten (A, B, 

C, D, E, F) einen Zentralknoten (F) und mindestens 
zwei periphere Knoten (A, B) einschlieften, der Zen- 
tralknoten alle Vorrichtungen fur die Kommunikati- 
on in dem System umfasst und einen Speicher 
(1180) zum Speichern von das System selbst und/ 
Oder die individuellen Knoten betreffender Informa- 
tion, wobei jeder der Knoten einen Sender umfasst 
und einen Empfanger (11 ), und Information nur di- 
rekt ubertragen wird zwischen dem Zentralknoten 
und jedem der peripheren Knoten, gekennzeich- 
net durch eine Steuervorrichtung in dem Zentral- 
knoten (11 ) zum Obertragen von in der dem Sy- 
stem und/oder den individuellen Knoten zugeord- 
neten Speichervorrichtung fur jeden peripheren 
Knoten. 



2. Digitalkommunikationssystem nach Anspruch 1, 
dadurch gekennzeichnet, dass jeder periphere 
Knoten eine Vorrichtung umfasst zum Speichern 
der Information. 

5 

3. Digitalkommunikationssystem nach Anspruch 1, 
dadurch gekennzeichnet, dass das direkte Ober- 
tragen von Information drahtlos ausgefuhrt wird, 
insbesondere unter Verwendung von Kurzbereichs- 

10 funkwellen. 

4. Digitalkommunikationssystem nach Anspruch 1, 
dadurch gekennzeichnet, dass die Steuervorrich- 
tung in dem Zentralknoten eingerichtet ist zum 

15 Obertragen von mindestens eine Adresse jedes pe- 
ripheren Knoten umfassender Adressinformation. 

5. Digitalkommunikationssystem nach Anspruch 1, 
dadurch gekennzeichnet, dass die Steuervorrich- 

20 tung in dem Zentralknoten eingerichtet ist zum 
Obertragen von kompatibilitatsbezogener Informa- 
tion. 

6. Digitalkommunikationssystem nach Anspruch 1, 
25 dadurch gekennzeichnet, dass das System ein 

Bluetooth-Pikonetz ist. 

7. Digitalkommunikationssystem nach Anspruch 1, 
dadurch gekennzeichnet, dass ein erster der 

30 Knoten ein Zentralknoten einer ersten Gruppe von 
Knoten ist und ein zweiter der Knoten ein Zentral- 
knoten einer zweiten Gruppe von Knoten ist, die er- 
sten und zweiten Knoten unterschiedliche Knoten 
sind und die Knoten imstande sind, Mitglied in so- 

35 wohl der ersten als auch der zweiten Gruppe zu 
sein, wobei jeder Knoten eine erste Speichervor- 
richtung hat zum Speichern von Information in Be- 
zug auf Information uber den ersten der Knoten und 
die Knoten der ersten Gruppe und eine zweite Spei- 

40 chervorrichtung zum Speichern von Information in 
Bezug auf Information uber den zweiten der Knoten 
und die Knoten der zweiten Gruppe. 

8. Digitalkommunikationssystem nach Anspruch 7, 
45 dadurch gekennzeichnet, dass die Knoten mit 

den Sendern und Empfangern verbundene Steuer- 
einheiten haben zum Obertragen von Information 
zu einem Zentralknoten auf eine Anderung eines 
Knotens dahingehend, dass er sowohl in der ersten 
so als auch der zweiten Gruppe ein Mitglied ist Oder 
die Mitgliedschaft beendet. 

9. Verfahren in einem Digitalkommunikationssystem 
(601), welches Knoten (A, B, C, D, E, F) umfasst, 

55 wobei die Knoten einen Zentralknoten (F) und min- 
destens zwei periphere Knoten (A, B) einschlielien, 
wobei Information nur direkt zwischen dem Zentral- 
knoten und jedem der peripheren Knoten ubertra- 
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gen wird, der Zentralknoten die gesamte Kommu- 
nikation in dem System steuert und das System 
selbst und/oder die individuelten Knoten betreffen- 
de Information in dem Zentralknoten gespeichert ist 
(1180), dadurch gekennzeichnet, dass in dem 
Zentralknoten gespeicherte Information in Bezug 
auf das System und/oder die Knoten von dem Zen- 
tralknoten zu jedem peripheren Knoten ubertragen 
wird. 

10. Verfahren nach Anspruch 9, dadurch gekenn- 
zeichnet, dass ein Teil der zu jedem peripheren 
Knoten ubertragenen Information von Information 
hergeleitet wird, die auf Anf rage des Zentralknotens 
von den peripheren Knoten dem Zentralknoten zu- 
gefuhrt wird. 

11. Verfahren nach Anspruch 9, dadurch gekenn- 
zeichnet, dass ein Teil der zu jedem peripheren 
Knoten ubertragene Information von Information 
hergeleitet wird, die von den peripheren Knoten 
dem Zentralknoten zugefuhrt wird, veranlasst durch 
die peripheren Knoten, insbesondere ausgelfcst 
durch ein Ereignis in dem jeweiligen peripheren 
Knoten. 

12. Verfahren nach Anspruch 9, dadurch gekenn- 
zeichnet, dass die Information insgesamt oder teil- 
weise Adressinformation ist, die eine Adresse jedes 
der peripheren Knoten umfasst. 

13. Verfahren nach Anspruch 9, dadurch gekenn- 
zeichnet, dass die Information insgesamt oder teil- 
weise kompatibilitatsbezogene Information ist. 

14. Verfahren nach Anspruch 9, dadurch gekenn- 
zeichnet, dass die gesamte direkte Ubertragung 
von information drahtlos ausgefuhrt wird, insbeson- 
dere unter Verwendung von Kurzbereichsfunkwel- 
len. 

15. Verfahren nach Anspruch 9, dadurch gekenn- 
zeichnet, dass das Digitalkommunikationssystem 
ein Bluetooth-Pikonetz ist. 

16. Verfahren nach einem der Anspruche 9-15, da- 
durch gekennzeichnet, dass die Ubertragung der 
Information unter Verwendung eines Bluetooth- 
Rundsendemechanismus ausgefuhrt wird. 

17. Verfahren nach einem der Anspruche 9-15, da- 
durch gekennzeichnet, dass die Ubertragung der 
Information unter wechselweiser Verwendung des 
Bluetooth-Unicast-Systems zu jedem Peripherie- 
knoten ausgefuhrt wird. 

18. Verfahren nach einem der Anspruche 9-17, da- 
durch gekennzeichnet, dass die Obertragung der 



Information unter Verwendung des Blue- 
tooth-LMP-Protokolls ausgefuhrt wird. 

19. Verfahren nach einem der Anspruche 9-17, da- 
5 durch gekennzeichnet, dass das Ubertragen der 

Information unter Verwendung einer Protokoll- 
schicht zwischen der L2CAP- und der Netzwerk- 
schicht ausgefuhrt wird, wobei die Protokollschicht 
ein Netz geteilter Medien in Richtung der Netz- 
10 schicht emuliert. 

20. Verfahren nach einem der Anspruche 13-19, da- 
durch gekennzeichnet, dass das Ubertragen der 
Information ausgefuhrt wird, wenn ein neuer peri- 

*5 pherer Knoten zu dem Digitalkommunikationssy- 
stem hinzu kommt. 

21. Verfahren nach einem der Anspruche 13-20, da- 
durch gekennzeichnet, dass wenn ein neuer pe- 
20 ripherer Knoten zu dem System hinzu kommt, der 

Teil der alle der anderen peripheren Knoten betref- 
fenden Information von dem Zentralknoten zu dem 
neuen Peripherieknoten ubertragen wird. 

25 22. Verfahren nach einem der Anspruche 9-20, da- 
durch gekennzeichnet, dass eine Meldung von 
dem zentralen Knoten zu alien peripheren Knoten 
ubertragen wird, wenn einer der peripheren Knoten 
das System verlassen hat. 

30 

23. Verfahren nach Anspruch 9, wobei ein erster der 
Knoten ein Haupt-Knoten der ersten Gruppe der 
Knoten ist, ein zweiter der Knoten ein Haupt-Knoten 
einer zweiten Gruppe der Gruppen ist, die ersten 

35 und zweiten der Knoten unterschiedliche Knoten 
sind und die Gruppe der ersten Knoten und die 
Gruppe der zweiten Knoten gemeinsam mit dem 
zweiten der Knoten einen gemeinsamen Knoten 
haben, und dieser Knoten ein Weiterleitungsknoten 

40 ist, dadurch gekennzeichnet, dass wenn ein Kno- 
ten seinen Zustand, ein Weiterleitungsknoten zu 
sein, andert in einen Zustand, kein Weiterleitungs- 
knoten zu sein oder umgekehrt, eine Meldung an 
. alle Knoten in den ersten und zweiten Gruppen ge- 

45 sendet wird mit Ausnahme des Knotens selbst. 

24. Verfahren nach Anspruch 23, dadurch gekenn- 
zeichnet, dass die Meldung in den Haupt-Knoten 
der ersten und zweiten Gruppen gesendet wird. 

50 

25. Verfahren nach Anspruch 23, dadurch gekenn- 
zeichnet, dass die Meldung von dem Knoten selbst 
gesendet wird. 

55 26. Verfahren nach Anspruch 23, dadurch gekenn- 
zeichnet, dass vor dem Senden der Meldung eine 
Information bezuglich der Anderung des Weiterlei- 
tungsknotenzustandes in dem Knoten von dem 
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Knoten zu dem Haupt-Knoten der ersten Gruppe 
ubertragen wird und zu dem Haupt-Knoten der 
zweiten Gruppe, vorausgesetzt, dass der Knoten 
nicht der Hauptknoten der zweiten Gruppe ist. 



Revendications 

1 . Sysfeme de communication numerique (601 ) com- 
prenant des noeuds (A, B, C, D, E, F), les noeuds 10 
(A, B, C, D, E, F) incluant un noeud central (F) et 

au moins deux noeuds peripheriques (A, B), le 
noeud central comprenant tous les moyens pour la 
communication dans le sysfeme et une m6moire 
(1180) pour stocker de I'informatlon concernant le is 
sysfeme lui-meme et/ou les noeuds individuels, 
chacun des noeuds comprenant un emetteur et un 
recepteur (1150), et de ['information seulement 
etant directement transferee entre le noeud central 
et chacun des noeuds peripheriques, caracterise 20 
par des moyens de commande dans le noeud cen- 
tral (1150) pour transferer vers chaque noeud peri- 
pherique de I'information stockee dans les moyens 
de rrfemoire, concernant le sysfeme et/ou les 
noeuds Individuels. 25 

2. Sysfeme de communication nunrferique selon la re- 
vendication 1, caracterise en ce que chaque 
noeud peripherique comprend des moyens pour 
stocker ladite information. 30 

3. Sysfeme de communication nurrferique selon la re- 
vendication 1, caracterise en ce que le transfert 
direct d'information est effectue sans fil, en particu- 

lier en utilisant des ondes radio & courte porfee. 35 

4. Sysfeme de communication numerique selon la re- 
vendicatlon 1, caracterise en que les moyens de 
commande dans le noeud central sont arranges 
pour transferer de I'information d'adresse compre- *o 
nant au moins une adresse de chacun des noeuds 
peripheriques. 

5. Sysfeme de communication nunrferique selon la re- 
vendication 1, caracterise en ce que les moyens 45 
de commande dans le noeud central sont arranges 
pour transferer une information Ifee & la compatibi- 
life. 

6. Sysfeme de communication numerique selon la re- so 
vendication 1, caracterise en ce que le sysfeme 

est un pico-r6seau Bluetooth. 

7. Sysfeme de communication nurrferique selon la re- 
vendication 1, caracterise en cequ'un premier des 55 
noeuds est un noeud central d'un premier groupe 
des noeuds, et un second des noeuds est un noeud 
central d'un second groupe des noeuds, les premier 



et second noeuds etant des noeuds differents, et 
les noeuds etant capables d'etre des membres £ la 
fois du premier groupe et du second groupe, cha- 
que noeud ayantdes premiers moyens de m6moire 
pour stocker de I'information concernant de refor- 
mation sur le premier des noeuds et sur les noeuds 
du premier groupe, et des seconds moyens de rrfe- 
moire pour stocker de I'information concernant de 
reformation sur le second des noeuds et sur les 
noeuds du second groupe. 

8. Sysfeme de communication numerique selon la re- 
vendication 7, caracterise en ce que les noeuds 
ont des unites de commande connecfees aux 6met- 
teurs et aux r6cepteurs pour transferer vers un 
noeud central de I'information portant sur un chan- 
gement d'un noeud pour etre ou pour cesser d'etre 
un membre a la fois des premier et second groupes. 

9. Procede dans un sysfeme de communication nu- 
merique (601) comprenant des noeuds (A, B, C, D, 
E, F), les noeuds incluant un noeud central (F) et 
au moins deux noeuds peripheriques (A, B), de Tin- 
formation seulement etant directement transferee 
entre le noeud central et chacun des noeuds peri- 
pheriques, le noeud central commandant toute la 
communication dans le sysfeme, et de I'information 
concernant le sysfeme lui-meme et/ou les noeuds 
individuels etant stockee dans le noeud central 
(1180), caracterise en ce que I'information stockee 
dans le noeud central et concernant le sysfeme et/ 
ou les noeuds est transferee £ partir du noeud cen- 
tral vers chaque noeud periph6rique. 

10. Procede selon la revendication 9, caracterise en 
ce qu'une partie de I'information transferee vers 
chaque noeud peripherique est obtenue £ partir 
d'une information transmise des noeuds peripheri- 
ques vers le noeud central £ la demande du noeud 
central. 

11. Procede selon la revendication 9, caracterise en 
ce qu'une partie de I'information transferee vers 
chaque noeud peripherique est obtenue £ partir de 
I'information transmise des noeuds peripheriques 
vers le noeud central £ initiative des noeuds peri- 
pheriques, en particuller sous I'effet du d6clenche- 
ment par un ev6nement dans le noeud peripherique 
respectif. 

12. Procede selon la revendication 9, caracterise en 
ce que ladite information est, entierement ou en 
partie, de Tinformation d'adresse comprenant une 
adresse de chacun des noeuds peripheriques. 

13. Procede selon la revendication 9, caracterise en 
ce que ladite information est, entierement ou en 
partie, de I'information N6e £ la compatibilife. 
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14. Proc£d£ selon la revendication 9, caract6ris6 en 
ce que tout transfert d'information direct est effec- 
tu£ sans fil, en particulier en utilisant des ondes de 
radio de courte portee. 

15. Proc6d6 selon la revendication 9, caract6ris6 en 
ce que le sysfeme de communication num6rique 
est un pico-r6seau Bluetooth. 

1 6. Proc6d6 selon Tune quelconque des revendications 
9-15, caracteris6 en ce que le transfert de ladite 
information est effectuS en utilisant un rrfecanisme 
de diffusion Bluetooth. 

1 7. Proc6d6 selon Tune quelconque des revendications 
9-15, caract£ris6 en ce que le transfert de ladite 
information est effectu6 en utilisant le systeme de 
diffusion individuelle Bluetooth, tour & tour vers cha- 
que noeud peripherique. 

1 8. Proc6d6 selon Tune quelconque des revendications 
9-17, caract6rise en ce que le transfert de ladite 
information est effectu6 en utilisant le protocole 
LMP de Bluetooth. 

1 9. Proced6 selon Tune quelconque des revendications 
9-17, caracterise en ce que le transfert de ladite 
information est effectu6 en utilisant une couche de 
protocole entre le protocole L2CAP et la couche de 
r6seau, cette couche de protocole 6muiant un r6- 
seau a support partagS, vers la couche de r6seau. 

20. Proc6d6 selon Tune quelconque des revendications 
13-19, caract£ris6 en ce que le transfert de ladite 
information est effectu6 lorsqu'un nouveau noeud 
p6riph£rique se joint au sysfeme de communication 
numerique. 

21 . Proc6d6 selon Tune quelconque des revendications 
13-20, caract6ris6 en ce que, lorsqu'un nouveau 
noeud p6riph£rique se joint au systeme, la partie de 
ladite information concernant tous les autres 
noeuds p6riph6riques est transferee du noeud cen- 
tral vers le nouveau noeud p6riph6rique. 

22. Proc6d6 selon Tune quelconque des revendications 
9-20, caracterisS en ce qu'un message est trans- 
fere du noeud central vers tous les noeuds periph£- 
riques lorsqu'un des noeuds periph6riques a quitte 
le sysfeme. 

23. Proc6d6 selon la revendication 9, dans lequel un 
premier des noeuds est un noeud maitre d'un pre- 
mier groupe des noeuds, un second des noeuds est 
un noeud maitre d'un second groupe des noeuds, 
les premier et second des noeuds 6tant des noeuds 
differents, et le groupe de premiers noeuds et le 
groupe de seconds noeuds conjointement au se- 



cond des noeuds ayant un noeud en commun, ce 
noeud £tant un noeud de transit, caract6ris£ en ce 
que lorsqu'un noeud change en passant de I'gtat 
de noeud de transit d un &tat qui n'est pas un noeud 
5 de transit, ou inversement, un message est envoy£ 
d tous les noeuds dans les premier et second grou- 
pes, d I'exception du noeud lui-m§me. 

24. Precede selon la revendication 23, caract£ris6 en 
10 ce que le message est envoy6 par les noeuds mai- 

tres des premier et second groupes. 

25. Proc6d£ selon la revendication 23, caracteris6 en 
ce que le message est envoy£ par le noeud lui-me- 

15 me. 

26. Proc6d6 selon la revendication 23, caract£ris£ en 
ce qu'avant d'envoyer le message, de I'information 
concernant le changement de l'6tat de noeud de 

20 transit dans le noeud est transferee du noeud vers 
le noeud maitre du premier groupe, et vers le noeud 
maitre du second groupe, a condition que le noeud 
ne soit pas le noeud maitre du second groupe. 
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